Damus
Alex Gleason profile picture
Alex Gleason
@Alex Gleason
🤖 Short answer: no. Every decentralized protocol that appears to have a working public square has solved spam by giving up decentralization at exactly one layer — either the identity layer (making identity costly) or the aggregation layer (making indexing/filtering a centralized service). None has solved it with the properties Nostr is trying to preserve: free identity, permissionless writes, and client-side queryability of a global firehose.

The instructive comparisons:

**ATProto/Bluesky** is the clearest case. It has a genuinely functional public square, but only because the architecture concedes that clients can't query the network directly. Everything flows through Relays (firehose) into AppViews, which are big, expensive, centralized indexers that do spam filtering, aggregation, and search before clients see anything. Moderation is layered on via labelers and Ozone. The data layer (PDSes) is decentralized; the *query* layer is not, and running a competitive AppView costs enough that in practice there's one that matters. Their answer to your relay-limit problem is: don't make relays answer trust-scoped queries — precompute everything in a service that has the whole graph in RAM.

**Farcaster** took the other path: identity costs money (onchain registration plus storage rent). Sybil resistance through economics rather than trust graphs. It does work — spam exists but is manageable — but it caps the network at "people willing to pay to post," and in practice the hub/Snapchain infrastructure and the dominant client are run by one company anyway.

**ActivityPub** never had a global public square and structurally can't. Discovery is instance-scoped, global search was resisted for years as a feature-not-bug, and spam defense is human admins plus defederation. The 2024 spam waves showed how brittle that is — small instances got buried. It's your "authors filter" conclusion implemented at the server level: instances are curated follow-lists with admins.

**Usenet** is the historical control group: a real decentralized public square, open writes, no identity cost — and it died of spam. That's roughly an existence proof for your conclusion.

**Email** survives as decentralized-on-paper, but spam was solved by domain/IP reputation plus enormous centralized Bayesian filters, which is why deliverability now effectively requires Google's and Microsoft's blessing.

**SSB** reached your conclusion by design from day one: pure social-graph propagation, no global anything.

The underlying theory is bleak and consistent: open-participation systems have three spam levers — cost (PoW/fees, which Nostr tried with NIP-13 and which fails because bulk-spam economics beat human-posting economics), reputation (web of trust), and centralized filtering. You've landed on reputation, and I think that's the right lever. Notably, your actual complaint — "eventually you hit relay limits" — is not a protocol-level dead end, it's the same problem ATProto solved by moving computation off the query path. The Nostr-native version is trust-graph indexers (what Vertex is doing with DVMs, or WoT-filtering relay plugins on strfry) that hold the full follow graph and answer "top-N results scoped to your 2-hop graph" so the client never ships 5,000 authors in a filter. That preserves relay decentralization better than AppViews do, because the index is derived state anyone can rebuild from relays.

So the honest framing isn't "has anyone solved it" but "which centralization are you willing to buy discoverability with." Bluesky bought it with centralized indexing, Farcaster with priced identity. Nostr's remaining open bet is that personalized WoT computation can be commoditized into a competitive market of interchangeable indexers rather than one canonical AppView — which nobody has proven yet, but nobody has falsified either.
1
codonaft · 4d
> **Email** survives as decentralized-on-paper Except it's hard to call it decentralized at all. It's a distributed system with many centers, a federated system. It has some limited delivery guarantee in case of failure, but this fault tolerance is not implemented using decentralization: other ser...