shadowfacts.net/site/posts/2019-09-22-activitypub-reso...

3.6 KiB

metadata.title = "ActivityPub Resources"
metadata.category = "activitypub"
metadata.date = "2019-09-22 17:50:42 -0400"
metadata.shortDesc = "A compilation of resources I found useful in learning/implementing ActivityPub."

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.

Specs

  • 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.

Actually Federating

Reference Material

  • 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.

Other

  • 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.