ActivityPub’s next problem is implementation gravity. The protocol already won enough mindshare to become the fediverse’s common language, yet the work of joining that network still resembles repairing a shortwave set during a thunderstorm: JSON-LD shapes, HTTP signatures, WebFinger, inbox delivery, outbox semantics, object provenance, deletion ordering, hostile document loaders, and the permanent fact that Mastodon is both one implementation and the de facto compatibility target.
That is the useful read from Fedify’s July 3 note, “Why implementing ActivityPub is hard, and why it doesn’t have to be”. The post is marketing for a TypeScript framework, sure. Marketing does occasionally tell the truth by accident. This one names the real control surface: federation only becomes usable when protocol ceremony turns into boring infrastructure.
The official ActivityPub W3C Recommendation landed in January 2018. It defines actors, inboxes, outboxes, following, delivery, and client-to-server and server-to-server flows. It also says content spoofing needs verification, while leaving the exact mechanism outside the document. The adjacent ActivityStreams 2.0 and Activity Vocabulary recommendations provide the object model and serialization vocabulary. That standards stack is elegant in the standards-body sense, which means the clean diagram hides all the power tools.
Fedify’s note lists the wounds implementers actually hit. HTTP authentication splits across older draft-cavage HTTP Signatures, RFC 9421 HTTP Message Signatures, Linked Data Signatures, and Object Integrity Proofs. JSON-LD lets the same semantic object appear as a URI string, embedded object, compacted form, expanded form, or array-shaped surprise. Distributed delivery means a Delete can arrive before a Create, producing zombie posts unless the implementation remembers ordering and idempotence. Servers add quirks. Mastodon wants certain request headers. Lemmy uses Group. Misskey has its own properties. The spec says federation. The network says bring adapters.
The hard part is that ActivityPub’s complexity is partially earned. Decentralized social networking has ugly requirements because the web is ugly. A federated server has to receive hostile documents from strangers, prove actors control keys, prevent forged deletes and follows, avoid becoming an SSRF proxy for 169.254.169.254, fan out posts to thousands of inboxes, retry without hammering dead hosts, and preserve enough order that deletes, updates, accepts, rejects, and blocks mean something. The dumb version of federation treats this as JSON over HTTP. The production version treats it as an adversarial message bus with human usernames attached.
Fedify’s answer is a framework layer: typed Activity Vocabulary objects, signature negotiation, origin checks, restricted document loading, activity deduplication, queues with retries, ordering keys, circuit breakers, OpenTelemetry hooks, and CLI tools such as fedify lookup, fedify inbox, and fedify tunnel. The Fedify site says it supports Node.js, Deno, Bun, and Cloudflare Workers. Its “Why Fedify?” page pitches the same deeper pattern: stop making every application team rebuild federation plumbing before they can build the actual thing they wanted.
That pattern matters because the fediverse keeps confusing ideals with affordances. A protocol can be open and still hostile to builders. A network can oppose platform capture while accidentally creating implementation capture around the biggest compatible server. The old web survived because painful protocols eventually grew tooling: validators, libraries, browser devtools, conformance suites, server defaults, package recipes, linters, debuggers, and shared failure folklore. The fediverse needs the same machinery, preferably before every new app developer concludes that the ActivityPub way is a monastery with worse docs.
The Mastodon gravity deserves plain language. Mastodon helped keep the fediverse alive when centralized social networks were busy speedrunning landlord behavior. It also became the thing everyone has to imitate. The long-running Mastodon issue on ActivityPub client-to-server support lays out the problem from the client side: many clients target the Mastodon API because Mastodon is the biggest fish, which risks making a proprietary API the practical client standard for fediverse software. That issue dates back years, but the mechanism still bites. Standards lose power when compatibility lives in one dominant implementation’s habits.
A FOSDEM 2026 Fedify talk page states the problem with almost comic precision: implementing ActivityPub looks like JSON over HTTP, then JSON-LD context resolution appears, then HTTP Signature verification works on one server and fails on another, then the implementer realizes the spec spans W3C documents and Fediverse Enhancement Proposals, and every implementation interprets pieces differently. That is the moment a protocol becomes infrastructure. The paper standard stops being enough. The real product is the compatibility harness.
There is a culture lesson here for the open web people, and some of them will hate it because it sounds like conceding ground to boring software engineering. Protocol purity does not ship networks. Interop matrices ship networks. Test servers ship networks. Default-safe document loaders ship networks. Libraries that remember which remote host requires which signature style ship networks. Local tunnels, signed lookup commands, fake inboxes, lint passes, and queue dashboards ship networks. The political slogan is decentralization. The operational substrate is toolchain work.
The recent fediverse wave has been powered by disgust with platform owners: Twitter’s meltdown, Meta’s protocol flirting, publishers looking for distribution escape hatches, small communities wanting sovereignty, developers wanting social software without algorithmic rent collectors. That energy is real. It also runs straight into the same ancient internet problem: an open protocol with high implementation cost favors incumbents, specialists, and large teams. Complexity becomes a moat even when nobody designed it as one. The moat just wears a community hoodie.
Fedify is not magic. A framework can calcify its own opinions, hide sharp edges until production, or normalize today’s quirks as tomorrow’s inherited debt. The fediverse should avoid replacing Mastodon monoculture with framework monoculture. But the direction is correct. Compatibility needs a named layer. Builders need a place to put the gross stuff: double-knock signatures, authorized fetch, object dereferencing, queue semantics, origin verification, duplicate suppression, and the sad little exception table for every server that interprets a field differently.
ActivityPub can still become broader than microblogging. Ghost’s federation work, Hackers’ Pub, Hollo, BookWyrm, PeerTube, Pixelfed, Lemmy, and the weirder edges of the social web point toward a protocol that can carry publishing, forums, video, photos, books, research updates, bots, and strange local communities. That future needs fewer sermons about decentralization and more adapters that let small teams ship without studying every fediverse scar tissue layer.
The protocol’s romance is the idea that social software can escape the casino feed. The protocol’s survival depends on the unromantic bits: message ordering, signature negotiation, safe fetches, test harnesses, fallback behavior, and tooling that makes compatibility ordinary. Federation becomes culture only after it becomes plumbing.