I use Mastodon on and off but I would not trade it for any alternative atm. Not because it’s better than Twitter was, the discoverability is worse, the reply threading is too complex at times, and it does have sync issues across instances. What it does have is something no corporate platform will ever offer: you can leave and take your social graph with you. Your followers, your follows, your block lists. Pack them up, point your domain at a different server, done.
That’s not a selling-point, it’s the absence of a lock-in mechanism. And it only works because ActivityPub is a real protocol that people actually implement.
We’re about to see a lot more of this.
Protocols that ship
ActivityPub shipped. That’s the part people gloss over. The fediverse has millions of users across thousands of instances. It’s not a whitepaper. It’s not a “we’re exploring decentralized architectures” blog post from a company that’ll pivot to AI next quarter. People use it every day, and they use it to talk to people on completely different servers running completely different software. Mastodon talking to Pleroma talking to Pixelfed talking to PeerTube. Same protocol, different UIs, different moderation policies, different vibes.
The protocol layer is the part that matters. Implementations come and go. Mastodon might fade. Something better will replace it. But ActivityPub will still be there, and the network effects built on top of it won’t evaporate the way they do when a single company burns out.
Email works the same way. Nobody owns email. You can run your own mail server (people do, I’ve done it, it’s a pain but it works) and you can send mail to anyone on any provider. The protocol is the platform. Everything else is just a client.
What’s missing
Git forges. That’s the obvious one.
GitHub has been the default for so long that we forget it doesn’t have to be. Git itself is decentralized. Every clone is a full copy of the repository. But issues, pull requests, code review, CI configuration, releases, wiki pages. None of that is in the repo. It’s in GitHub’s database. When GitHub goes down, your code is fine but your workflow is gone. When GitHub makes a decision you hate, you can move your repos but you can’t move your issues. The community is stuck to the platform.
ForgeFed is an attempt to fix this. It’s an ActivityPub extension that defines vocabulary for repositories, commits, patches, issues, merge requests. The idea is that your forge, wherever it’s hosted, can interact with any other forge that speaks ForgeFed. You open an issue against a repo on someone else’s server without creating an account there. You submit a patch from your self-hosted Gitea instance to a project on a friend’s Forgejo instance. Same protocol, different UIs, same as the fediverse already does for social media.
It’s early. Vervis is the reference implementation, mostly a testbed for the protocol. Forgejo is working on federation support, but the discussion about enabling it on Codeberg gives you a sense of where things actually stand: the features are real enough that Codeberg’s team is planning the rollout, but they’re also worried about scaling surprises, DDoS amplification, and moderation gaps. The largest Forgejo instance in the world can’t just flip a switch and see what happens. Pagure had a plugin that’s unmaintained now. Nobody would call this production-ready. But the direction is right, and the pieces exist.
Why now
AI makes protocols cheap again.
Here’s what I mean. Writing a protocol is not the expensive part. An RFC is a text file. The expensive part is iterating on it. You write a spec, someone implements it, they find ambiguities, you revise the spec, someone else implements the revision, they interpret it differently, you add clarifications, and on and on. Each cycle costs developer time. The longer the cycles, the slower the protocol converges. And the slower it converges, the less likely anyone is to bet on it.
AI changes the economics of this. If an LLM can draft a reference implementation in an afternoon, you can test a protocol revision against real code the same day you write the spec change. You can have multiple implementations in different languages from the same spec, each revealing different assumptions. You can generate compliance tests, edge case tests, interop tests. The feedback loop shrinks from months to hours.
This doesn’t replace the human work of protocol design. Trade-offs still need judgment. But it removes the biggest bottleneck: the gap between “here’s the spec” and “here’s code that proves it works.”
Beyond protocols: UX contracts
There’s a further step I keep thinking about. Protocols define data formats and message flows. They don’t define what the user sees. Two ActivityPub implementations can have wildly different UIs, and they do, and that’s fine for power users who know what they’re signing up for. But for federation to reach people who don’t want to think about protocols, you need something more.
Call it a UX contract. Not a wireframe spec, not a design system. Something lighter. A set of guarantees about what the user can expect. If you open a merge request on a federated forge, the interface for reviewing it should be recognizable. The terminology should be consistent. The notification flow should feel familiar. Not identical. Just not alien.
This is harder than a protocol spec. UX is squishy. But AI makes squishy things cheaper too. You can generate UI scaffolding from a UX contract the same way you generate network code from a protocol spec. You can test whether different implementations feel coherent to a user. You can iterate on the contract without waiting for a design team to hand off mockups to an engineering team.
I don’t think we’re there yet. But the path is visible. Protocols define what the machines say to each other. UX contracts define what the humans expect to see. Both need to be cheap to iterate on, and both are getting cheaper.
The bet
Centralized platforms win on convenience. Self-hosting wins on control. Federation splits the difference: you get control over your own data and your own instance, but you’re not isolated. You’re still in the network.
The fediverse proved this works for social media. It’s not perfect. Moderation at scale is unsolved, instance discovery is clumsy, the UX is uneven. But it works, and it’s growing, and nobody can shut it down.
Git forges are next. ForgeFed might not be the thing. Something else might emerge. But the pattern is set. Protocols over platforms. Federation over centralization. And with AI making the iteration loop tighter, we’re going to see protocols ship faster than they ever have before.
I want my code, my issues, my review history, and my community to outlast whatever forge I’m using. Same way my email outlasts whatever client I’m using. Same way my social graph outlasts whatever Mastodon instance I’m on. The protocol is the platform. Everything else is just a client.