ActivityPub: the W3C Standard Behind Federated Social Networks

Federated social networks like Mastodon and Misskey, collectively known as the "Fediverse," are not built on a single central server, but on countless independent servers exchanging messages with one another to form one giant social network. ActivityPub is the protocol that defines how that delivery works. This deep dive covers the Actor model, inbox/outbox delivery, the trust and discovery mechanisms of HTTP Signatures and WebFinger, and how interoperability plays out across real implementations.

What is ActivityPub: the W3C Recommendation behind federated social networking

ActivityPub became an official W3C Recommendation in January 2018. Drafted by the W3C Social Web Working Group, it is an open federation protocol for implementing social-networking features, defining common social behaviors (posting, following, liking, sharing) as standardized messages that can be exchanged between servers. ActivityPub itself specifies how messages are delivered and how actors interact; the vocabulary for the data itself (posts, profiles, and so on) comes from a separate W3C Recommendation, ActivityStreams 2.0, expressed in JSON-LD (a JSON format for linking machine-readable vocabulary terms).

The idea of "federation" resembles email: countless independent servers (instances) running software like Mastodon each operate on their own, yet communicate with one another to form a single, much larger network. Users create an account on whichever instance they prefer, while still being able to follow, reply to, and quote users on other instances. This is a design philosophy shared broadly across federated protocols in general.

The Actor model: inbox/outbox, Activity, and Object

At the heart of ActivityPub is the Actor. Actors come in types such as Person (an individual), Group, Organization, Application, and Service (an automated service), and each one carries, alongside its profile information, two special URLs (endpoints): an inbox and an outbox. When an actor posts something, it is added to that actor's own outbox and simultaneously delivered to its followers' inboxes. Conversely, follow requests and reactions from other actors arrive in one's own inbox.

All interaction between actors happens through an object called an Activity, a verb-like piece of data describing who did what to whom. The common ones are Create (make a post), Update, Delete, Follow paired with Accept/Reject, Like, and Announce (rebroadcasting someone else's post to your own followers, i.e. a boost or repost), along with Undo, which reverses a prior Activity. The thing an Activity wraps is called an Object: a short post is a Note, a longer piece of writing is an Article, and there are also Image, Video, and Event object types.

How delivery works: server-to-server federation, HTTP Signatures, and WebFinger

The ActivityPub specification defines two protocols: C2S (Client-to-Server), for exchanging Activities between a client and its server, and S2S (Server-to-Server, federation), for servers delivering Activities to one another. In practice, only S2S sees wide adoption: most major implementations, Mastodon included, do not implement the C2S half, instead using their own bespoke REST or streaming APIs for client communication.

When a user posts something, their server resolves the inbox URLs from that user's follower list, serializes the Activity as JSON-LD, and delivers it via an HTTP POST to each inbox. Sending individually to every follower on the same remote server is wasteful, so implementations commonly optimize by sending a single copy to the shared inbox referenced by endpoints.sharedInbox on the Actor object, letting the receiving server fan it out locally to its own followers.

• HTTP Signatures: the sending server signs the headers of its POST request with the private key paired to the public key published on its Actor profile. The receiving server fetches that public key and verifies the signature, preventing spoofing and confirming the sending actor's authenticity. The mechanism is based on an IETF draft (draft-cavage-http-signatures) and is not part of the ActivityPub specification itself, but because major implementations like Mastodon refuse to accept unsigned Activities in what is called "authorized fetch" or secure mode, it has become a de facto requirement in practice.
• WebFinger (RFC 7033): starting from a familiar, email-like handle such as @user@example.com, a client queries the /.well-known/webfinger endpoint on example.com to resolve the corresponding user's ActivityPub profile URL (their Actor object). This is the standard entry point for discovering users across different servers.

The implementation ecosystem: different services following one another

By speaking a common ActivityPub vocabulary, a wide range of purpose-built services can federate with one another, letting users follow and reply across service boundaries.

As long as a service implements the shared Actor/Activity/Object vocabulary and the common inbox/outbox delivery path, interactions across dissimilar services (a forum user commenting on a video-sharing post, for instance) become possible in principle.

Challenges and limitations

• Fan-out delivery cost: when an account with tens or hundreds of thousands of followers posts, its server must send an individual HTTP POST to each of the potentially thousands of distinct remote servers those followers are spread across. Shared inboxes consolidate deliveries bound for the same server, but as the diversity of servers grows, so does the delivery load.
• Spam and moderation: the openness that lets anyone stand up a server and join the federation also makes it a potential source of spam and harmful content. Instance administrators commonly handle this through defederation (blanket-blocking inbound traffic from specific servers) or blocklists, though this comes with the side effect of fragmenting the wider network.
• Dialects and interoperability issues between implementations: because the ActivityStreams 2.0 vocabulary is designed to be extensible, implementations often bolt on their own extensions (custom reactions, quote posts, and the like) inconsistently, so a feature that works in one implementation frequently fails to render correctly in another.
• No guaranteed propagation of deletion or privacy: sending a Delete Activity does not guarantee the receiving remote server actually purges the data; that depends entirely on the recipient's implementation and policies, with nothing in the protocol to enforce it. Visibility controls, such as follower-only posts, likewise rely on the good-faith cooperation of the receiving server's implementation.
• Weak account migration: the Move activity together with the alsoKnownAs/movedTo properties provides a way to carry followers over from an old account to a new one, but in most implementations the actual post history is not migrated and remains stranded on the old server.

Comparison with other federated protocols

Protocols aiming at similar goals include AT Protocol, used by Bluesky, and Nostr, a simpler design built around relay servers. AT Protocol keeps each user's data in a repository on their own PDS (Personal Data Server), giving it stronger account portability than ActivityPub, at the cost of a more complex overall architecture. Nostr ties actor identity to a public key in a way conceptually close to decentralized identifiers, with lightweight relays standing in for servers as message relays, resulting in a more minimalist design overall. The detailed comparisons live on their respective pages.

Related pages

The idea ActivityPub embodies, servers federating with one another as equals, connects to several other topics on this site. The broader design philosophy of federated architectures is covered in Federated Protocols; actor identity and account migration concepts are explored in Decentralized Identifiers (DID); a rival protocol built around a more cryptography-centric design is covered in Nostr; and the more data-sovereignty-oriented approach taken by Bluesky is covered in AT Protocol.