ActivityPub Won by Being Boring - Owl Owl OÜSkip to content≡

At FediForum 2026, Evan Prodromou gave a talk with the kind of title only a protocol co-author can get away with: “How To Bullshit Your Way Through a Conversation about ActivityPub.”

The joke worked because the speaker had no need to bluff. Prodromou is one of the five authors listed on the W3C ActivityPub Recommendation and the author of O’Reilly’s ActivityPub book. The self-deprecating frame covered an honest architecture talk about why the Fediverse works at all.

His running gag was that every term could be treated as a portmanteau. Fediverse is federated plus universe. ActivityPub is activity plus publishing. RESTful, in his groaner version, is rest plus full. Fine. Protocol people deserve hobbies too.

Behind the jokes was a serious claim: ActivityPub works because its core is intentionally ordinary. It is impressive in the way a good loading dock is impressive. Trucks arrive. Boxes move. Nobody writes a poem about the forklift.

Any competent Web engineer from the mid-2010s could look at ActivityPub and think, yes, this is roughly how I would have done it.

If you want the primer before the argument, start with What Is ActivityPub?. This piece is about why those familiar parts mattered.

The protocol part is deliberately dull

Federation starts with a modest agreement. Independent networks agree to exchange activity data. They do not agree on a database, a moderation model, an admission policy, a user interface, a ranking system, or a product category.

That minimum agreement is the important part. Mastodon, PeerTube, Lemmy, WriteFreely, Pixelfed, WordPress, and small single-user servers keep their own shape. It is why our Mastodon service on C.IM, PeerTube service on P.LU, and Lemmy service on R.NF can share a social graph without becoming one product.

The ActivityPub specification describes two layers: a client-to-server API and a server-to-server federation protocol. In practice, the server-to-server part is where most Fediverse operators feel the machinery. Actors have inboxes and outboxes. Servers deliver activities to remote inboxes. Other servers fetch actor documents, objects, and collections by URL.

The model is almost aggressively plain. An activity is a sentence: subject, verb, object. Alice liked the article. Bob followed Alice. A server created a note. Someone announced a post. The thing crossing the wire is often the sentence about the content, not merely the content itself.

That distinction makes ActivityPub social. A content-sync protocol can move articles and images. A social protocol also has to move reactions, follows, blocks, shares, undo operations, and the context that makes those actions meaningful.

Prodromou’s funniest historical aside was that the activity concept traces back to 1930s Soviet activity theory, associated with psychologist Alexei Leontiev, and then wandered through user-experience research before landing in Activity Streams. The Fediverse running on repurposed Marxist psychology sounds like satire written by committee. Protocol concepts rarely arrive cleanly from first principles; they get dragged in from wherever the previous generation left useful tools.

The transport is even less exotic. ActivityPub uses HTTP. Fetch an actor’s URL to learn about the actor. POST an activity to an inbox to deliver it. The spec’s overview says the quiet part directly: inboxes and outboxes are URLs, and federation usually happens by servers posting messages to other servers’ inboxes.

Even the familiar user@domain handle is not fundamental to ActivityPub. It comes through WebFinger, a modernization of older Internet identity lookup habits. The protocol needs identifiers. Humans like handles because @[email protected] fits in a search box better than a full actor URL.

This is why ActivityPub spread. JSON-ish objects, HTTP GET, HTTP POST, URLs, collections, actors, inboxes, outboxes. None of this is dazzling. Boring is implementable.

The technical debt is less charming

Boring protocols still accumulate weird debt. ActivityPub has a good example sitting in authentication.

The Fediverse commonly uses HTTP Signatures for server-to-server request authentication. The awkward part is which HTTP Signatures. The deployed Fediverse grew around the older draft-cavage-http-signatures-12, an Internet-Draft that is now expired and archived. The IETF work later produced RFC 9421, HTTP Message Signatures, published in February 2024, with a different design.

Minimum-consensus evolution looks like this in practice: a draft is useful enough, implementers ship, the network grows, and the official standard arrives later with a different shape. Nobody can fix that by saying “the spec says” loudly at a server log.

Security has another blunt edge. ActivityPub has addressing. A to field can say which actor or collection an activity is intended for. Servers can deliver only to addressed recipients, and they can check authorization...