Dave Winer posted a 12-minute audio recording on his blog, addressed to me but applicable to everyone who is creating tools for the social web. Listening to it, I have a bunch of thoughts. In this post, I just want to start with server-to-server ActivityPub, and leave some of the other technologies Dave brings up for later.
A few days ago I was revisiting the ActivityPub code in Micro.blog because we have some interoperability problems with Calckey, now called Firefish. Firefish is a Mastodon-like platform with a few unique design twists and features. To narrow down where things were going wrong, I read through the ActivityPub spec again and also looked at JSON responses from other platforms like Mastodon and Bridgy Fed.
To frame this blog post I’ll put forward this question, at the heart of interoperability on the fediverse:
Is it possible to implement a social web platform by reading the suite of ActivityPub specs, and have that new platform be compatible with Mastodon?
I would argue no, it is not possible. A new project would only be compatible with Mastodon by accident because there are some things that are not spelled out in precise detail in the specifications, and no JSON examples that exactly match what any server sends or expects. The specs have all the pieces, but not how to fit those pieces together.
In addition to the specs, Mastodon’s own documentation is very good, and it has improved even in the last year. But again, if you ask a developer to implement ActivityPub, they will naturally start at the W3C.
I hope this doesn’t sound overly critical. The fact is, ActivityPub is complicated, and by design this kind of architecture can only be simplified so much. A lot of great work came out of the W3C’s Social Web Working Group, including IndieWeb standards, and I don’t think the authors had enough time to get consensus on some parts of ActivityPub before publishing, nor could they predict everything a platform like Mastodon or Micro.blog might need. Recently, Evan Prodromou has been leading the effort to address GitHub issues and move things forward.
I said “suite” of ActivityPub specs above because ActivityPub is not really one thing. There’s the ActivityPub spec itself, but also ActivityStreams, HTTP Signatures, WebFinger, JSON-LD, and the working group note on authentication.
And there are other features, such as account migration between instances, that are not documented outside of Mastodon. This is why the IndieWeb principles warn of monoculture. We are lucky that Mastodon cares deeply about the open web, because other dominant platforms might have less incentive to make their extensions work outside their own ecosystem.
The current fediverse is impressive. It’s further along than most people would’ve guessed possible a few years ago, largely thanks to Mastodon’s polish and Twitter’s implosion. The next step should be getting to the point where the answer to my question above can be “yes”. How can new developers add support for ActivityPub without feeling like they are reverse-engineering every existing server?
We don’t necessarily need a new spec, although it would be helpful to have a single document that ties everything together — a guide that a developer could use to build something and be confident that it has a chance of being compatible with other platforms. I also think we should consider further simplification, such as making JSON-LD optional (!) and drafting a streamlined version of ActivityStreams with only the bare minimum object types that most servers need.
There is a lot of work to do, even outside of ActivityPub. As Dave mentions, we also need a common posting API. The most popular Mastodon client apps do not support either ActivityPub or Micropub. But a lot of progress can be made focusing on interoperability for the server-to-server part of the API. That should be the top priority with Threads set to join the fediverse.
