Andrew Mercer
on this page

What it is

ActivityPub is a W3C Recommendation, standardized in 2018, that defines how independent servers exchange social-networking activity — posts, follows, likes, boosts, deletions — over plain HTTP. It's the protocol underneath Mastodon, but also PeerTube (video), Pixelfed (photos), Lemmy (link-aggregation/forums), WriteFreely (blogging), and dozens of smaller implementations, all of which can interoperate because they speak the same wire protocol even though they're wildly different kinds of applications. This shared network of ActivityPub-speaking servers is what people mean by "the fediverse."

Architecture

ActivityPub defines two distinct layers, and an implementation can support either or both:

  • Client-to-server ("Social API") — how your own client (a phone app, a web UI) talks to your home server to create, update, or delete content, on your behalf.
  • Server-to-server (federation) — how independent servers exchange activities with each other. This is the layer that actually makes it "federated."

Every participant — a person, but also bots, groups, and applications — is an actor, and every actor has two key endpoints described in its ActivityStreams profile document:

  • An inbox: where the actor receives activities from the world (POST to deliver a message to someone).
  • An outbox: where the actor's own activities live (POST to publish; GET to read them back).

Federation, mechanically, is one server doing an HTTP POST of a JSON activity into another actor's inbox URL. Mastodon's own tutorial diagrams this about as plainly as it can be diagrammed: posting is "put it in your outbox," and federation is "your server POSTs it into every follower's server's inbox." Note that Mastodon specifically doesn't use the outbox-GET pattern for federation the way the spec technically allows — it pushes directly to inboxes, which is a Mastodon implementation choice rather than something ActivityPub requires.

The data model: ActivityStreams

The JSON payloads themselves aren't ActivityPub-specific — they're ActivityStreams 2.0, a separate W3C vocabulary that predates and underlies ActivityPub. It defines:

  • Core types: Object, Link, Activity, Collection, OrderedCollection, and their paged variants.
  • Activity types: Create, Update, Delete, Follow, Accept, Reject, Like, Announce (Mastodon's "boost"/repost), Undo, Block, Flag, and more — the verbs of the network.
  • Object types: Note (a short post), Article, Image, Video, Person, Group, Application, Service — the nouns.

Because this is JSON-LD, servers are free to extend the vocabulary with their own custom types and properties without breaking older implementations that don't understand them — they just ignore what they don't recognize. That flexibility is also ActivityPub's biggest practical weakness: since each server interprets the loosely-typed JSON according to its own logic rather than against a strict schema, cross-implementation behavior can legitimately diverge (two servers can disagree about what a given activity means), which is part of why interoperability quirks between different ActivityPub apps are common in practice.

Discovery: WebFinger

Before Server A can deliver to @[email protected], it needs to turn that handle into an actual inbox URL. That's WebFinger — a separate, older, general-purpose protocol ActivityPub piggybacks on. A GET to https://example.social/.well-known/webfinger?resource=acct:[email protected] returns a JSON Resource Descriptor (JRD) pointing to Alice's actual ActivityPub actor document, which in turn lists her inbox, outbox, followers, and following collections.

Identity and moderation

Your identity, @[email protected], is inseparable from the instance hosting it. This is ActivityPub's central tradeoff: it's simple and requires no separate identity layer, but it means your account, post history, and (without prior setup) your followers disappear if your instance shuts down. Mastodon supports account migration — moving to a new instance while redirecting followers — but it has to be set up in advance, and it doesn't carry your post history with it.

Moderation happens at two levels. Instance admins set and enforce local rules for their own users. And instances can defederate — refuse to accept activities from another server entirely. This is coarse (it's an all-or-nothing decision about an entire server, not individual accounts) but it's been the fediverse's actual mechanism for handling bad-actor instances, spam farms, and harassment campaigns. Your experience of "the network" is shaped by which instance you're on and which servers it has chosen to defederate from — a dependency that's easy to overlook until it matters.

Recent developments worth knowing

Mastodon shipped quote posts in version 4.5 (late 2025), a long-resisted feature the team had avoided for years over concerns about enabling "dunking" (quoting to mock, out of context) — they shipped it with author-side controls (quoting can be disabled globally or per-post, quoted authors are notified and can detach their post from a quote after the fact). Cross-implementation quote support is being standardized via FEP-044f (Fediverse Enhancement Proposal), since ActivityPub itself has no built-in concept of quoting.

Strengths and weaknesses

Strengths: mature, W3C-standardized, powers a genuinely diverse set of app types (not just microblogging), simple mental model (HTTP POST to an inbox), no company owns the protocol.

Weaknesses: identity is instance-bound with no portability by default; loosely-typed payloads mean cross-implementation behavior can be inconsistent; defederation is a blunt instrument; moderation load falls entirely on volunteer instance admins.

Further reading