This isn’t really going to be a blog most, but more of a collection of tidbits and resources I found helpful in implenting the ActivityPub integration for the new version of my blog.
This post was last updated on Oct 10, 2019.
- The ActivityStreams 2.0 spec is important, as it’s what ActivityPub is built on top of.
- Similarly, the AS 2.0 Vocabulary defines all the objects and activities that AP actually uses in practice (and many more that it doesn’t).
- The ActivityPub spec itself is quite useful, despite its many omissions.
- There’s also LitePub, which has some extensions to AP.
- The least useful by far spec is JSON-LD which defines how to use JSON to represent linked data and objects graphs. AS2 and AP are both built on this, but if you’re going for a simple implementation (or even a complex one), you can entirely ignore this and treat JSON-LD as plain old JSON objects.
This is also a helpful resource about how to go about reading the AP specification.
- Gargron’s blog posts on implementing a basic AP server and implementing HTTP signatures are good guides for how to actually get federating with other servers in the wild.
- Lain’s blog post on some of the weird quirks of how ActivityPub actually gets used.
- Kaniini’s blog post about how data actually moves through the fediverse.
- Darius Kazemi has a simple reference implementation of an ActivityPub server written using Node.js.
- I used the Pleroma source code a great deal when working on my implementation, mainly just because I’m familiar with Elixir.
- I’d also like to think my own implementation is fairly approachable (it’s about 700 lines of not-too-complicated TypeScript).
- Ted Unangst has a collection of sample data which is useful for comparing how different implementations represent things in AP.
- For actually testing federation, ngrok is very useful for testing your implementations against others. It creates a tunnel from your local machine to a public domain with HTTPS already setup. Because your code is still running locally, you have access to all your usual debugging tools and can iterate rapidly.
- Testing against other implementations running locally (be it on your machine or inside a VM/container) lets you access debug logs and see what the other server is actually receiving, which can be quite useful.
- Ted Unangst also has his own compilation of AP-related links.