Nostr Is Centralizing. By Design
Nostr basics are simple and powerful. A keypair, a signed event, a relay. The primitives are perfectly on point.
But there's a problem: most of the specifications shipped before the tooling existed to implement it properly. Every Nostr builder had to fill the gap with whatever they had at hand. Which happened to be centralized infrastructure.
There was not a single decision that made it wrong, but the issue is that they compound. And we are slowly rebuilding Twitter out of reasonable choices.
"Decentralized" is a spectrum measured by the cost to a motivated adversary to degrade or surveil the network. Right now, that cost is embarrassingly low — not because the protocol failed, but because each missing primitive got replaced by a shortcut that stuck.
01. default relay lists are a single point of failure
Every major client ships with a hardcoded default relay list. Damus, Primal, Amethyst — they all do it. When they launched, relay discovery didn't exist, so developers hardcoded whatever was up and reliable. Rational. Temporary.
Except temporary became permanent. The practical network is now 10–15 well-known servers. Operators know this. Governments know this. Three relays comply with a court order and I lose write access to the social graph I thought was mine.
A decentralized system with centralized defaults is a centralized system — just with extra latency.
02. NIP-65 is correct. it's also widely ignored.
NIP-65 defines two lists on my profile: relays I write to (outbox) and relays I read from (inbox). If everyone publishes to their own declared relays, data distributes naturally — my notes live where I chose to put them. My client fetches your notes from your declared relays, not from a central index. The network topology mirrors the social graph.
In practice the outbox side partially works. The silent failure is the fallback: if my relay is slow, the client writes to a default relay with no indication this happened. The inbox side is worse — most clients query the same 10–15 big relays and assume my notes got there through replication. Sometimes they did. Often only partially.
NIP-65 depends on relays gossiping with each other. That gossip layer was never properly built. So clients can't trust that fetching from declared relays returns a complete picture — and fall back to the big ones.
Which is self-fulfilling. Big relays accumulate everything because clients keep writing there as backup, making them more complete, making clients depend on them more. Clients tried enforcing the outbox model strictly — notes went missing, people complained, enforcement got reverted. So NIP-65 gets lip service in readmes and silent override in production.
03. algorithmic feeds need someone to run the algorithm
The moment a client offers smart feeds or discovery, it needs to index the entire network — or outsource it. Primal does its own indexing. So does yakihonne. Clients are becoming front-ends to these services, and my keypair doesn't protect me from a feed curated by an infrastructure provider with its own business model and jurisdictional exposure.
Without proper relay distribution, I can't do discovery from the edges — I need someone in the middle with a full index. The aggregator fills the gap, becomes load-bearing. The algorithm is back. It just speaks WebSocket.
04. paid relays recreate platform economics
Paid relays make sense as spam defense. But they're also natural aggregation points. Quality content gravitates to relays with uptime and filtering. Readers follow content. Network effects kick in. The paid relay market will consolidate into a handful of dominant providers — exactly as happened with email hosting and every other federated protocol that touched commercial incentives.
The relay operator becomes the new platform. They have my IP, my payment, my social graph. I've rebuilt Substack on a different wire format.
05. spam got solved at the wrong layer
Relay-level spam filtering — proof of work, payment, invite-only — made sense in 2022. WoT tooling didn't exist, social graph data was too sparse, and operators needed to protect their resources now. So they built gates. It worked.
That's precisely the problem. A working solution removes the pressure to build the correct one — protocol-level Web of Trust filtering, cryptographic, portable across relays. It never got built because relay-level gating already "solved" spam. WoT remains underspecified, most clients treat it as optional, and every new relay defaults to the same gatekeeping pattern.
The good-enough answer didn't just delay the right answer. It made it structurally unnecessary — until the whole architecture depended on the workaround.
06. clients compete on retention, not sovereignty
Client developers face the same incentives as every social app: DAU, session length, revenue. The features that matter for decentralization — relay diversity, WoT filtering, local event caching — are invisible to me and impossible to pitch. The features that drive retention — algorithmic feeds, push notifications, polished onboarding — are easy to ship and easy to justify.
Sovereignty doesn't have a metric. So it gets deprioritized every sprint until it's a toggle in settings that nobody opens. The incentive structure makes this choice — not the developers.
07. the incentive model is broken by design
Relay operators and I want different things — and the protocol doesn't reconcile that.
An operator's incentive is uptime, cost control, spam prevention. None of that requires serving my data reliably. A relay that silently drops events from low-traffic accounts is still commercially viable. To the operator, acceptable loss. To me, my content disappearing without explanation.
I want my data on my terms. The operator wants a sustainable business. In the absence of protocol enforcement, their incentives win — they control the infrastructure.
Paid relays don't fix this. What I'm buying is write access, not guaranteed availability. Free relays have the inverse problem — they run on goodwill, and when that runs out the relay goes down and takes its history with it. In both cases, there's no cryptographic guarantee that my data persists. I'm trusting infrastructure the same way I trust a cloud provider — which is exactly what I was supposed to be escaping.
08. developers missed the point
There's another failure layer that doesn't get talked about enough — how developers themselves relate to the protocol.
Nostr turns out to be a convenient backend. No database to maintain. No GDPR compliance headaches. No auth system to build. Publish a signed event, let relays handle storage, done. There are threads on Stacker News where developers seriously ask whether they can replace their database with a Nostr relay — using it as a personal key-value store for note-taking apps, with no interest in censorship resistance or social graphs. Just "it's easier than running Postgres."
This isn't wrong exactly. The protocol allows it. But it reflects a pattern: a growing share of the ecosystem is being built by developers who discovered Nostr as infrastructure convenience, not as a censorship-resistance primitive. The result shows. Apps that connect to a single hardcoded relay. Clients that skip key management UX because "users don't care." Projects that use Nostr for coordination but store the actual data on S3.
There's even a GitHub repo — awesome-nostr-possibilities — that exists specifically because people noticed Nostr was being treated as "Yet Another Social Media Protocol" and nothing more. The repo title is a warning: Nostr will fail if it stays just another social media protocol. That warning is from 2023. The ecosystem didn't listen.
The protocol's openness — the feature that makes it powerful — is being harvested for convenience while the properties that make it meaningful get quietly discarded.
The missed opportunity is real. Nostr is not a backend shortcut. It's infrastructure for a new trust model — signed data, portable identity, user-controlled social graphs. Developers who treat it as a database replacement are building on the foundation without understanding what the foundation is for. And every app they ship that ignores sovereignty makes the network a little more normal, a little more like what we already have.
09. true sovereignty is currently a power user feature
This is where the failure becomes structural in a different way: right now, genuine data sovereignty on Nostr requires running your own relay. That means a server, a domain, maintenance, cost. It's achievable — but only for people with the technical depth and motivation to do it.
Everyone else trusts the default relay list and calls it decentralized.
The protocol promised sovereignty to all users. What it delivered is sovereignty for those willing to operate infrastructure — and a false sense of it for everyone else.
This isn't entirely a failure. It might actually be the honest model. Not every user needs the same level of sovereignty, and not every user should bear the same infrastructure burden. But the current ecosystem doesn't make that tradeoff legible — it presents casual relay usage as equivalent to self-sovereign storage, which it isn't.
The honest version of Nostr looks tiered: power users run their own relays, control their data end-to-end, and get cryptographic guarantees. Everyone else chooses a relay they trust, accepts the tradeoff, and gets at least a portable identity and censorship resistance at the key layer — even if not at the storage layer. That's still meaningfully better than Web2. But it requires being honest that full sovereignty isn't the default, it's something you have to build for yourself.
What's missing is the tooling to make that path accessible. A one-click personal relay. Storage commitments that are verifiable without running your own infrastructure. WoT-based reputation for relay operators so I can make an informed trust decision rather than defaulting to whoever the client hardcoded.
The ceiling for power users is high. The floor for everyone else is lower than it should be. The gap between them is where most of the ecosystem lives — and where most of the centralization hides.
what needs to change
WoT filtering needs to be the default, not an option. The tools exist — NIP-02, NIP-51, graph distance scoring. The gap is prioritization.
Relay diversity needs to be visible. Show me how many unique relays my notes replicate across. I respond to signals I can see.
Outbox Model fallbacks need to be auditable. If a client writes to a default relay because mine was slow, that should be logged and visible — not a silent background decision.
The path to self-sovereign storage needs to get easier. One-click personal relays, verifiable storage commitments, relay reputation via WoT — these lower the floor without limiting the ceiling.
the verdict
Every centralization point here was a rational response to a missing tool. Default relay lists because relay discovery wasn't ready. Aggregators because client-side indexing was too hard. Relay-level spam filters because WoT didn't exist. Developers building on convenience because the deeper value proposition wasn't visible to them.
Each solved problem removed the pressure to build what would have prevented the next one. Slow structural decisions, each reasonable, compounding into something broken. That's harder to fix than bad intent — because there's nothing to point at.
The protocol is still worth building on. But not by pretending it delivers what it doesn't yet. Decentralization is not a feature you add later. It's a constraint you build under from day one — or you spend years retrofitting it into an ecosystem that already optimized around its absence.
Building WoT infrastructure for Nostr at nostr-wot.com