The fediverse was right · Ata Kuyumcu's Blog
search
&]:hidden" viewBox="0 0 20 20" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" aria-hidden="true"><br>&]:block" viewBox="0 0 20 20" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" aria-hidden="true"><br>https://blog.lvmbdv.dev/posts/the-fediverse-was-right/Photo by National Cancer Institute on UnsplashI use Mastodon on and off but I would not trade it<br>for any alternative atm. Not because it’s better than Twitter was, the<br>discoverability is worse, the reply threading is too complex at times, and it<br>does have sync issues across instances. What it does have is something no<br>corporate platform will ever offer: you can leave and take your social graph<br>with you. Your followers, your follows, your block lists. Pack them up, point<br>your domain at a different server, done.<br>That’s not a selling-point, it’s the absence of a lock-in mechanism. And it only<br>works because ActivityPub is a real protocol that<br>people actually implement.<br>We’re about to see a lot more of this.<br>Protocols that ship<br>ActivityPub shipped. That’s the part people gloss over. The fediverse has<br>millions of users across thousands of instances. It’s not a whitepaper. It’s not<br>a “we’re exploring decentralized architectures” blog post from a company that’ll<br>pivot to AI next quarter. People use it every day, and they use it to talk to<br>people on completely different servers running completely different software.<br>Mastodon talking to Pleroma talking to<br>Pixelfed talking to<br>PeerTube. Same protocol, different UIs, different<br>moderation policies, different vibes.<br>The protocol layer is the part that matters. Implementations come and go.<br>Mastodon might fade. Something better will replace it. But ActivityPub will<br>still be there, and the network effects built on top of it won’t evaporate the<br>way they do when a single company burns out.<br>Email works the same way. Nobody owns email. You can run your own mail server<br>(people do, I’ve done it, it’s a pain but it works) and you can send mail to<br>anyone on any provider. The protocol is the platform. Everything else is just a<br>client.<br>What’s missing<br>Git forges. That’s the obvious one.<br>GitHub has been the default for so long that we forget it doesn’t have to be.<br>Git itself is decentralized. Every clone is a full copy of the repository. But<br>issues, pull requests, code review, CI configuration, releases, wiki pages. None<br>of that is in the repo. It’s in GitHub’s database. When GitHub goes down, your<br>code is fine but your workflow is gone. When GitHub makes a decision you hate,<br>you can move your repos but you can’t move your issues. The community is stuck<br>to the platform.<br>ForgeFed is an attempt to fix this. It’s an ActivityPub<br>extension that defines vocabulary for repositories, commits, patches, issues,<br>merge requests. The idea is that your forge, wherever it’s hosted, can interact<br>with any other forge that speaks ForgeFed. You open an issue against a repo on<br>someone else’s server without creating an account there. You submit a patch from<br>your self-hosted Gitea instance to a project on a friend’s Forgejo instance.<br>Same protocol, different UIs, same as the fediverse already does for social<br>media.<br>It’s early. Vervis is the reference implementation, mostly<br>a testbed for the protocol. Forgejo is working on<br>federation support, but the<br>discussion about enabling it on Codeberg<br>gives you a sense of where things actually stand: the features are real enough<br>that Codeberg’s team is planning the rollout, but they’re also worried about<br>scaling surprises, DDoS amplification, and moderation gaps. The largest Forgejo<br>instance in the world can’t just flip a switch and see what happens. Pagure had<br>a plugin that’s unmaintained now. Nobody would call this production-ready. But<br>the direction is right, and the pieces exist.<br>Why now<br>AI makes protocols cheap again.<br>Here’s what I mean. Writing a protocol is not the expensive part. An RFC is a<br>text file. The expensive part is iterating on it. You write a spec, someone<br>implements it, they find ambiguities, you revise the spec, someone else<br>implements the revision, they interpret it differently, you add clarifications,<br>and on and on. Each cycle costs developer time. The longer the cycles, the<br>slower the protocol converges. And the slower it converges, the less likely<br>anyone is to bet on it.<br>AI changes the economics of this. If an LLM can draft a reference implementation<br>in an afternoon, you can test a protocol revision against real code the same day<br>you write the spec change. You can have multiple implementations in different<br>languages from the same spec, each revealing different assumptions. You can<br>generate compliance tests, edge case tests, interop tests. The feedback loop<br>shrinks from months to hours.<br>This doesn’t replace the...