When someone equates the Fediverse with the Mastodon implementation, fedizens are sure to correct them. The Fediverse is a network of many different implementations that interoperate through the Fediverse protocol stack, although Mastodon is the dominate implementation.
When someone equates the Fediverse protocol stack with ActivityPub, they are making the same mistake. The two concepts are not the same thing, and the difference matters, and the rest of this article is explains why.
What is the Fediverse?
The Fediverse is a network of independently operated servers whose users can follow and reply to each other across server boundaries. The name is a portmanteau of federation and universe.
But, what is it, really? How does one know if a server is part of the Fediverse? There are varying opinions that cluster around two definitions. One definition is that the Fediverse is the network of federated social web servers regardless of the protocol used by a specific server. Multiple protocols can be federated using protocol bridges.
The narrower definition, that some people claim is more historically accurate, defines the Fediverse as the network of servers that use ActivityPub (or OStatus) protocols in some form. For the purposes of this article, I'm going to use this definition when discussing the Fediverse. However, in spirit, I fully support the broader view of multi-protocol federated social networks.
What is ActivityPub?
ActivityPub is a W3C Recommendation published in January 2018, built on Activity Streams 2.0. It specifies a message-passing protocol — the messages, message serialization, the endpoints that accept or provide them, and the side effects a receiving server is expected to produce.
It describes two protocols, client to server and server to server, and three conformance classes, one of which is the federated server. It defines a very minimal data schema. In general, there's no definition of required and optional properties, and serialization is very loosely defined.
There very little discussion of security issues, media management, search, and other functionality needed for providing an acceptable user experience and server federation. Because it is so minimally-defined, ActivityPub is very, very flexible. However, that flexibility is a big problem for real world, large-scale interoperable federated software networks.
The Fediverse Protocol.
The Fediverse protocol is effectively the protocol stack the Mastodon team built, and it is what servers on the network actually speak. The team worked alongside the ActivityPub authors while the Recommendation was being finished. For implementation purposes, they took the parts of the specification that solved Mastodon problems, extended what needed extending, and discarded the rest.
The goal was never to implement ActivityPub as such. It was to build a practical stack that could support a federated network of servers at scale: actor discovery, request authentication, delivery, media handling, timelines, moderation, and a client interface that a real application could use.
The result is a Fediverse serving over a million active users, although it is unfaithful to the ActivityPub Recommendation in some ways. It has become popular to criticize Mastodon for harming ActivityPub because it's doesn't completely follow the Recommendation. However, ActivityPub's lead author put the debt the other way round: “Mastodon saved ActivityPub.”
However, it's fair to note that Mastodon didn't save all of ActivityPub. The Mastodon team found nothing in the client-to-server half of the Recommendation that it needed, and did not implement it. The client side of the Fediverse today is the Mastodon Client API, plus a set of bespoke APIs specific to individual servers. There is some hope that this may change but progress is very slow at the moment.
To see the differences between the Fediverse protocol and ActivityPub, it's useful to see the capabilities side-by-side.
| Capability | Fediverse | ActivityPub |
|---|---|---|
| Server-to-server federation | ✓ | ✓ |
| Shared inbox delivery | ✓ | ✓ |
Public addressing through to and cc | ✓ | ✓ |
| Client-to-server API | Mastodon | AP C2S |
| Actor discovery through WebFinger | ✓ | ✗ |
| Server metadata through NodeInfo | ✓ | ✗ |
| Request authentication through HTTP Signatures | ✓ | ✗ |
| Media upload | ✓ | ✗ |
| Federated HashTags | ✓ | ✗ |
| Real-time streaming | ✓ | ✗ |
| Post visibility semantics | ✓ | ✗ |
| Notification policies | ✓ | ✗ |
Federation policy: secure mode, federated Block | ✓ | ✗ |
| Messaging Relays | ✓ | ✗ |
This table shows why ActivityPub on its own is not sufficient to implement a federated social network. The gap between the Recommendation and a working server is why I believe Nothing implements ActivityPub. The Recommendation only works in a Fediverse context because the community has been able to select a useful subset of the almost infinite flexibility of ActivityPub and find practical ways to address its confusing terminology and concepts. The ActivityPub Working Group may improve the situation by fixing errors in the specification and refining some of the concepts, but the changes will be relatively minor and are unlikely to change how the Fediverse works in practice.
The successful servers that were implemented after Mastodon typically did not attempt to implement the ActivityPub Recommendation. They adopted the Fediverse protocol as Mastodon defined it: the same delivery rules, the same signatures, and mostly the same extensions. The implementations differ from each other; the protocol they speak does not. Developers are free to be creative, but that creativity tends to be punished by interoperability challenges and very limited user interest.
The client side is the clearest evidence. Almost all server-independent Fediverse user interfaces implement the Mastodon Client API rather than the ActivityPub Client API, because that is where the users, the libraries and the shared developer knowledge are.
Most innovation in the Fediverse now happens at the edges of the existing protocol, in new object types, extensions and applications built on top of it, rather than in the core. Developers who concentrate on Mastodon compatibility are sometimes criticized for that. The criticism mistakes a practical strategy for a failure of ambition or creativity. I believe that compatibility with Mastodon is realistically the only existing interoperability strategy the network has.
Recommended Terminology
The Fediverse Protocol
The Fediverse protocol stack, originally developed by the Mastodon team and adopted and extended by the community over the last decade.
The Fediverse
The network of servers using the Fediverse protocol stack.
ActivityPub
The W3C Recommendation, of which a restricted subset is partially used and extended by the Fediverse for its messaging protocol. It is one element of the Fediverse protocol stack.
I'll refer back to this terminology in future articles about the Fediverse, ActivityPub and related topics.