• 01. Default Relay Lists
• 02. NIP-65 Is Correct. Also Widely Ignored.
• 03. Algorithmic Feeds Need Someone to Run the Algorithm
• 04. Paid Relays Recreate Platform Economics
• 05. Spam Got Solved at the Wrong Layer
• 06. Clients Compete on Retention, Not Sovereignty
• 07. Relay Operators and I Want Different Things
• 08. Many Developers Are Missing the Point Entirely
• 09. True Sovereignty Is a Power User Feature
• What Needs to Change
• The Verdict

I’ve been building on Nostr for a few weeks. Long enough to dig through the NIPs, run infrastructure, and notice the gap between what the protocol promises and what the ecosystem actually delivers.

The primitives are correct. Keypair, signed event, relay. Simple. The problem isn’t there.

The problem is the spec shipped before the tooling existed to implement it properly. Every builder since has rationally filled that gap with whatever was available. Which happened to be centralized infrastructure. No single decision was wrong. The compounding was.

> “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

Damus, Primal, Amethyst — they all ship with hardcoded relay lists. When they launched, relay discovery didn’t exist. So developers hardcoded whatever was up and reliable. Rational. Temporary.

Temporary became permanent. The practical network is 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. Also Widely Ignored.

NIP-65 defines outbox and inbox relay lists on my profile. If everyone publishes to their own declared relays, the network topology mirrors the social graph. No central pool. No single load-bearing relay.

In practice: outbox partially works. The inbox side is worse — most clients query the same 10–15 big relays and assume replication got there. Sometimes it did. Often only partially.

The deeper problem: NIP-65 depends on relays gossiping with each other. That gossip layer was never properly built. So clients can’t trust declared relays return 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. Strict outbox enforcement has been tried — notes went missing, people complained, enforcement got reverted. More than once.

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 to someone who does. Primal does its own indexing. So does Yakihonne. Clients are becoming front-ends to these services.

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, discovery from the edges is impossible — you 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. 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, podcast infrastructure, 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 complete sense in 2022. WoT tooling didn’t exist. Social graph data was sparse. 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. The correct solution is protocol-level WoT filtering — cryptographic, user-sovereign, portable across relays. It never got built because relay-level gating already “solved” spam.

> The good-enough answer didn’t just delay the right answer. It made it structurally unnecessary — until the whole architecture depended on the workaround.

WoT remains underspecified. Most clients treat it as optional. Every new relay defaults to the same gatekeeping pattern that calcified three years ago.

§06. Clients Compete on Retention, Not Sovereignty

Client developers face the same incentives as every social app: DAU, session length, revenue.

Features that matter for decentralization — relay diversity, WoT filtering, local event caching — are invisible to users and impossible to pitch. 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. Relay Operators and I Want Different Things

An operator’s incentive is uptime, cost control, spam prevention. None of that requires serving my data reliably. It requires serving enough data to keep people from leaving. 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, no cryptographic guarantee my data persists. I’m trusting infrastructure the same way I trust AWS — which is exactly what I was supposed to be escaping.

§08. Many Developers Are Missing the Point Entirely

This one is uncomfortable to say but needs to be said.

Nostr is a convenient backend. No database to maintain. No GDPR headaches. No auth system. Publish a signed event, let relays handle storage, done. There are threads on Stacker News with developers seriously asking if they can replace their Postgres database with a Nostr relay. No interest in censorship resistance. Just “it’s easier.”

The result shows in the ecosystem. Apps connecting to a single hardcoded relay. Clients skipping key management UX because “users don’t care.” Projects using Nostr for coordination but storing actual data on S3.

There’s a GitHub repo — awesome-nostr-possibilities — that exists specifically because people noticed Nostr was being treated as Yet Another Social Media Protocol. The repo’s own description is the warning: Nostr will fail if it stays just another social media protocol. That’s from 2023. The ecosystem didn’t course-correct.

> 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.

Nostr is not a backend shortcut. It’s infrastructure for a new trust model — signed data, portable identity, user-controlled social graphs. Every app that ships ignoring sovereignty makes the network a little more normal. A little more like what we already have.

§09. True Sovereignty Is a Power User Feature

Right now, genuine data sovereignty on Nostr requires running your own relay. A server. A domain. Maintenance. Cost. 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. What it delivered is sovereignty for those willing to operate infrastructure — and a false sense of it for everyone else.

This might actually be the honest model going forward. Not every user needs the same sovereignty level, and not every user should bear the same infrastructure burden. But the ecosystem doesn’t make that tradeoff legible — it presents casual relay usage as equivalent to self-sovereign storage. It isn’t.

The honest version of Nostr is tiered: power users run their own relays and get cryptographic guarantees. Everyone else picks a relay they trust and gets portable identity plus censorship resistance at the key layer — not at the storage layer. Still meaningfully better than Web2. But it requires honesty that full sovereignty is something you build for yourself, not something the default client config gives you.

What’s missing: a one-click personal relay. Verifiable storage commitments without running your own infrastructure. WoT-based relay reputation so I can make an informed trust decision instead of 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 is where most of the ecosystem lives — and where most of the centralization hides.

§What Needs to Change

WoT filtering as default, not an option. NIP-02, NIP-51, graph distance scoring — the tools exist. The gap is prioritization.

Relay diversity as a visible metric. Show me how many unique relays my notes replicate across. I respond to signals I can see.

Outbox Model fallbacks must be auditable. If a client writes to a default relay because mine was slow, that should be logged and visible — not a silent decision I can’t see or fix.

Lower the floor for self-sovereign storage. One-click personal relays. Verifiable storage commitments. Relay reputation via WoT. The ceiling is already there. The floor needs work.

§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 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 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.

See it for yourself, and test with your own data: <https://analytics.nostr-wot.com/>\
I am building a solution for this. On Nostr. Contact me to talk about it!