ActivityPub support

[strugee]

ActivityPub is a standards-track protocol for server-to-server federation, as well as client-to-server APIs at the W3C. https://www.w3.org/TR/activitypub/

My understanding is that this is something Mastodon is somewhat interested in already, but I'm filing an issue to have "somewhere" to track this.

---

Edit: here's a checklist for things to implement. I cut out client-to-server stuff, although most of it applies to both.

Does your application implement URLs for:

• Object id properties? (Section 3.2 Retrieving objects)
• Actor inboxes?
• Actor outboxes?
• Actor Following collections?
• Actor Followers collections?
• Actor Likes collections? (optional)
• Binary uploads? (Section 6 Uploading Media, optional)

Does your application handle:

• The special Public collection?
• Server-to-server Activity side effects, like Undo side effects?
• Linked Data Notifications RDF representations (very optional)? (Section 8.1 Delivery)

Do you:

• Properly support Actor simplified login naming? (Section 4)
• Deliver activities properly?
• Implement authentication and authorization checks for server-to-server interactions?
• Scrub Activities for cross-site scripting attacks?
• Have a plan for combating spam?

[Gargron]

Can you compile a checklist of things that need to be implemented to become AP-compliant from a server-to-server perspective? (Not interested in client-to-server at all, right now)

Something like inbox, outbox, representation of stuff, etc.

My biggest desire wrt. AP is the ability to implement follower-only messages as well as direct messages without leaking them to old GNU social server that don't understand privacy scopes. As far as I understand AP servers must respect the addressee collections, so it should be a thing out of the box, plus there are no old faulty AP servers to worry about leaking stuff to accidentally.

[Gargron]

cc @evanminto

[wilkie]

I'm already gearing up to look at what still needs to be done for implementing AP integration Friday through this weekend. I've been within the W3C group, so I have a good understanding of it already. Working off of the existing AP mastodon branch, of course. Anybody else want to look at it with me?

FTR that's also my biggest desire wrt what AP integration would provide.

[strugee]

@Gargron sure, I drew up a list for pump.io. pump-io/pump.io#1241 is our tracking issue but I have a generic version of that list that I'll find for you shortly

[Gargron]

I am suspecting that the first step is writing JSON representations of ActivityStreams items. Currently we do that for Atom XML only. The logic should be similar enough, except you'd probably write Rabl templates instead of using a class like AtomSerializer and Ox (although from a performance perspective, doing something with Oj directly without invoking Rabl would be a huge boost)

[strugee]

@Gargron yeah I'm not familiar with exactly how the OStatus protocol works but probably for any endpoint that would previously return some ActivityStreams XML you'll want to just content-negotiate and return JSON when needed. Note that ActivityStreams 2.0 also includes an appendix on how to "upgrade" ActivityStreams 1.0 objects to AS2, so you could probably just do that in the request handler and serve the result

[evanminto]

I didn't get very far in my AP integration before I got sidetracked by some personal life stuff, but there IS at least a basic example of what Gargron is talking about for representing accounts as Activity Streams 2.0 on master. I have some more unfinished work (rudimentary outboxes) on a private branch.

I was planning on jumping back into it a bit this weekend too, and I'm glad to have some more folks looking into it!

[evanp]

The ActivityPub network page on the w3c wiki has some info on the progress happening in other social networking software projects.

[wilkie]

That sounds like a reasonable first step: the ActivityStreams 2 data/vocab model. Get existing endpoints to render content-negotiated JSON (application/activity+json) for posts/feeds. I still need to look to see what the existing work does, but let's get a checklist... with this on top.

We should obviously validate against pump.io's AP implementation and any others that might be at all ahead: https://www.w3.org/wiki/Socialwg/ActivityPub_network (rstatus is on there... should I even? nono) and Soci-el and Pubstrate which are both a kind of reference implementation.

[strugee]

@Gargron added a checklist to the issue description

[strugee]

@wilkie note also the pump.io's implementation is in very early stages and is very much a WIP. That being said it's very high priority for us and I'm hoping to at least make good progress by the end of the month

[wilkie]

@strugee definitely understandable. hopefully we can work off of one another in terms of testing implementations. pump.io is obviously much more of a real-world federation than the reference libraries.

[strugee]

@wilkie definitely. I should note also that our implementation may be slightly wonky since we have a large existing network to worry about... but Mastodon has the same problem, and in an even worse form (since at least pump's existing stuff is pretty close to AP)