The Great Decentralization Swindle: How Every Protocol But One Betrays Its Promise

The eternal recurrence of centralization

There is a pattern in human affairs that repeats with depressing regularity. A technology emerges that promises to decentralize power. Enthusiasts celebrate. Entrepreneurs build. And then, slowly, the same old concentrations of control reassert themselves through new mechanisms.

We saw it with the internet itself, that great decentralizing force that somehow delivered us into the hands of five corporations. We see it now in the protocols that claim to offer an escape.

The word "decentralized" has become the most abused term in technology. To cut through this fog, we must be precise about what decentralization requires: identity sovereignty (your identity exists independent of any third party), censorship resistance (your voice survives the failure or hostility of any single node), and permissionless participation (anyone can join on equal terms).

Most protocols that call themselves decentralized fail at least one of these tests. Many fail all three.

---

ActivityPub: trading corporate overlords for hobbyist landlords

ActivityPub, the protocol underlying Mastodon, works through independent servers communicating with each other, passing messages in a grand federation. Users create accounts on servers, and those servers relay posts to the wider network.

The fatal flaw reveals itself immediately. Your identity is @[email protected], a string that depends entirely on a domain name controlled by someone else. Should the server operator ban you or grow tired of paying hosting bills, your identity evaporates. Your followers, your history, your accumulated social capital - gone.

The advocates speak of migration, of moving your account between servers. But this requires cooperation from both origin and destination. The server that wants to silence you bears no obligation toward your departure.

The economic dynamics compound the problem. Running a server demands continuous attention: updates, security patches, spam fighting, moderation, hosting costs. The protocol provides operators with enthusiasm as their only compensation. They run on enthusiasm, and enthusiasm fades. When it does, all data dies with them.

The predictable result is centralization toward the few servers with resources to persist. Mastodon.social dominates despite every stated intention otherwise. The pattern repeats across all federated systems: email promised decentralization and delivered Gmail's dominance.

Direct messages are readable by server administrators, and block lists are publicly queryable. ActivityPub offers distributed hosting, not decentralization. You have traded corporate overlords for hobbyist landlords.

---

AT Protocol: the Bluesky mirage

If ActivityPub represents the first wave of federated social networking, AT Protocol represents the second: more sophisticated and better funded, yet centralized in practice through the same structural pressures.

The marketing is seductive. AT Protocol promises "credible exit" (the ability to take your data and leave), algorithmic choice, and decentralization through a three-tier architecture.

Examine these promises closely and they dissolve.

Your identity uses either did:plc or did:web. The first is a database run by Bluesky - they control it completely. The second resolves to HTTPS URLs, meaning your identity depends on DNS and certificate authorities. If your domain registrar suspends your domain, your identity is gone.

But the deeper problem is key custody. When you create a Bluesky account, the platform generates your cryptographic keys and stores them on their servers. From Bluesky's own documentation: the signing key "lives exclusively in the PDS." If someone else generates your keys and stores them, they can sign messages as you, modify your data, or lock you out entirely.

The phrase "credible exit" requires trusting the entity you're exiting from. If Bluesky holds your signing keys, migrating requires their cooperation. This is permission-based exit masquerading as sovereignty.

To Bluesky's credit, alternative implementations exist. Blacksky, created by Rudy Fraser, provides a complete independent implementation in Rust. Users can migrate from Bluesky to Blacksky's infrastructure while maintaining their identity. This demonstrates that AT Protocol federation can work.

But Blacksky's existence also illustrates the barriers. The resource requirements for running the full stack remain prohibitive. A Relay needs storage growing at eighteen gigabytes daily. An AppView requires approximately half a million dollars in hardware. As of late 2024, Bluesky's Relay remained the only one serving the full network.

Bluesky may become a good Twitter replacement. But the architectural choices create natural centralization pressures that good intentions leave intact.

---

Matrix: the weight of history

Matrix emerged to create the "email of real-time communication." It has achieved notable successes: adoption by the German military, the French government, and numerous open-source communities.

But Matrix carries architectural burdens that make it unsuitable for lightweight sovereignty.

The identity problem mirrors ActivityPub: @user:homeserver.domain, bound to a server controlled by someone else. The same vulnerabilities apply.

More distinctive is Matrix's approach to data consistency. The protocol maintains complete, synchronized state for every conversation, replicating all history across all participating servers. When you join a room, your server must download every message ever sent, every membership change, every piece of metadata.

The reference server, written in Python, is notorious for resource consumption. Joining large public rooms can take minutes and often fails. The reference client, built on Electron, bundles an entire browser. The practical result is that participating in large public rooms requires significant hardware, creating centralization pressure toward well-funded operators.

For organizations wanting self-hosted Slack replacements within controlled environments, Matrix serves admirably. For individuals seeking freedom from centralized control, it recreates the dependencies they sought to escape.

---

Secure Scuttlebutt: the beautiful failure

Secure Scuttlebutt, born from Dominic Tarr's experiences on a sailboat with unreliable internet, represents the purest expression of offline-first, peer-to-peer social networking. Each user maintains an append-only log of signed messages that propagates through the network friend to friend.

The identity model is correct. Your identity is an Ed25519 keypair you generate locally, independent of any server or authority.

But the elegance conceals fatal limitations.

Append-only means exactly what it says: you cannot delete messages, ever. That ill-considered post from years ago remains permanently embedded, replicated across the devices of everyone who follows you.

If your private key is compromised, an attacker can append to your log forever. There is no key rotation that preserves your social connections. You would need to create an entirely new identity.

The storage model is where ambitions collide with reality. Each peer stores the complete feeds of everyone they follow plus friends-of-friends. Users report databases exceeding 1.3 gigabytes. Initial synchronization can take hours. As the network grows, the burden on each participant grows proportionally.

Scuttlebutt peaked at approximately ten thousand users in 2019. By 2021, active participation had dropped to around two hundred. It remains a fascinating experiment, but not a practical foundation for widespread use.

---

Farcaster and Lens: the cryptocurrency tax

A certain faction believes blockchain technology solves all coordination problems. This belief produced Farcaster and Lens Protocol, both requiring cryptocurrency for basic social functions.

Farcaster uses Ethereum to register identities. Creating an account requires ETH for gas fees. Maintaining storage requires ongoing payments. Lens Protocol goes further: the entire social graph is NFTs, every interaction a blockchain transaction.

The technical merits are real. Blockchain-based identity provides persistence and censorship resistance at the identity layer. But these merits matter less than a simple fact: requiring cryptocurrency excludes the vast majority of humanity.

Most people own no cryptocurrency and have no desire to acquire any. Expecting them to handle wallet setup, seed phrase management, and gas fees to post thoughts on the internet sets an insurmountable barrier.

Social media succeeds through network effects, which collapse when entry barriers rise. Cryptocurrency requirements are high barriers. The math does not work.

---

Why Nostr wins

Against this field of compromises, Nostr's simplicity becomes its greatest strength.

Identity without permission

Your identity is your keypair - specifically secp256k1, the same curve Bitcoin uses. You generate it locally: the public key is your identity, and the private key proves you control it.

That property is live in production, for every user, today.

Relays: dumb pipes, smart clients

Nostr consists of clients and relays: clients are the applications users interact with, and relays store and forward messages.

Relays are deliberately simple. They receive signed JSON events, validate signatures, store events, and serve them on request. Understanding the social graph is unnecessary; consistency with other relays is not required. Store and serve.

This simplicity makes relays cheap to operate - five to fifty dollars monthly on basic infrastructure. Anyone can run one. The hardware requirements are modest; no cryptocurrency stake is needed.

When a relay blocks you, you publish to another. Your followers, querying multiple relays, find your content. Relay coverage is decentralized, with no central registry. Publish to any relay that accepts your events.

Far more than microblogging

The most important thing to understand about Nostr is that it is not a social media application. It is a protocol for signed data. Social media is the first application built on top.

The protocol specification consists of NIPs - Nostr Implementation Possibilities. These are open documents anyone can write. NIP-01 defines the basic protocol. But the NIP process does not stop at social features.

Consider what has been built: microblogging clients like Damus, Amethyst, Primal, Snort, and dozens more. Long-form content platforms using NIP-23. Marketplaces where reputation becomes portable because every event is signed. Live streaming platforms like Zap.stream, chess games like Jester, code collaboration projects, and decentralized wiki initiatives.

This diversity is possible because the building blocks are simple and the specification process is open. If you want to build something new, you write a NIP describing your event kinds. You do not need permission from a foundation or approval from a standards body. Relays store events by kind number without needing to understand what they mean. Your new application works immediately on existing infrastructure.

The contrast with other protocols is stark. A new application on ActivityPub requires extending server software. AT Protocol demands defining Lexicons and ensuring AppViews understand them. Farcaster requires smart contract deployment. Nostr requires writing a document and publishing events.

Privacy when you need it

Nostr is public by default, appropriate for social broadcasting. But when you need privacy, the tools exist.

NIP-44 defines encryption using ChaCha20-Poly1305. NIP-17 defines "gift-wrapped" events that protect metadata by encrypting sender and recipient information.

For group messaging, the Marmot Protocol brings MLS (Messaging Layer Security) to Nostr. MLS is what powers Signal-style encryption, but adapted for decentralized networks. Marmot provides forward secrecy (past messages stay encrypted even if keys leak), post-compromise security (key rotation limits damage from future compromises), and efficient scaling for large groups. White Noise implements Marmot as a dedicated encrypted messaging app, demonstrating that Nostr can support Signal-grade privacy without Signal's centralized servers.

No cryptocurrency required

Nostr was designed by bitcoiners, and Lightning integration exists for those who want it. Zaps allow sending satoshis attached to notes. But none of this is required. You can use Nostr without owning any cryptocurrency, without understanding Bitcoin, without ever touching blockchain infrastructure.

---

The architectural insight

Every alternative protocol makes a fundamental compromise: they assume some trusted third party.

ActivityPub trusts server operators with your identity. AT Protocol trusts Bluesky with your cryptographic keys. Matrix trusts homeserver operators and exposes metadata to every server in every room. Scuttlebutt trusts that your key will never be compromised. Farcaster and Lens trust blockchain infrastructure and exclude anyone unwilling to acquire cryptocurrency.

Nostr trusts nobody. The protocol assumes adversarial conditions from the start. Your identity is a keypair you generated, beyond any institution's reach. Relay operators cannot read your encrypted messages. Publishing is open to any relay that accepts your events, and anyone can create a new relay.

fiatjaf, the creator of Nostr, observed something profound: if Bluesky clients became smart and started sourcing from multiple relays, talking directly to Personal Data Servers, doing all the things that would deliver on the promises of decentralization, they would end up reinventing Nostr with extra steps.

Complexity serves the interests of the powerful. Complex systems require expertise to manage, create barriers favoring incumbents, and provide endless opportunities for gatekeeping disguised as necessary administration.

The simple system is the democratic system. When anyone can understand the protocol, anyone can participate in building it. An infrastructure anyone can run admits no monopoly. An identity that requires nothing but a keypair cannot be sold back to you.

Nostr is not perfect. Key management remains challenging, though solutions like NIP-46 and hardware signing devices are emerging. Spam prevention is ongoing. Discovery mechanisms continue to evolve.

But these are implementation challenges within a sound framework. They are categorically different from the structural compromises that doom other protocols to recentralization.

The foundation is sound: your keys, your identity, forever.