# Censorship-resistant relay discovery in Nostr
In [Nostr is not decentralized nor censorship-resistant](nostr:naddr1qqyrsdmpxgcrsepeqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823c4n8rw6) I said Nostr is centralized. Peter Todd thinks it is centralized by design, but I disagree.
Nostr wasn't designed to be centralized. The idea was always that clients would follow people in the relays they decided to publish to, even if it was a single-user relay hosted in an island in the middle of the Pacific ocean.
But the Nostr explanations never had any guidance about how to do this, and the protocol itself never had any enforcement mechanisms for any of this (because it would be impossible).
My original idea was that clients would use some undefined combination of relay hints in reply tags and the (now defunct) `kind:2` relay-recommendation events plus some form of manual action ("it looks like Bob is publishing on relay X, do you want to follow him there?") to accomplish this. With the expectation that we would have a better idea of how to properly implement all this with more experience, Branle, my first working client didn't have any of that implemented, instead it used a stupid static list of relays with read/write toggle -- although it did publish relay hints and kept track of those internally and supported `kind:2` events, these things were not really useful.
[Gossip](https://github.com/mikedilger/gossip) was the first client to implement a [truly censorship-resistant relay discovery mechanism](https://mikedilger.com/gossip-relay-model.mp4) that used NIP-05 hints (originally proposed by [Mike Dilger](nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgua442w)) relay hints and `kind:3` relay lists, and then with the simple insight of [NIP-65](https://nips.nostr.com/65) that got much better. After seeing it in more concrete terms, it became simpler to reason about it and the approach got popularized as the "gossip model", then implemented in clients like [Coracle](https://coracle.social) and [Snort](https://snort.social).
Today when people mention the "gossip model" (or "outbox model") they simply think about NIP-65 though. Which I think is ok, but too restrictive. I still think there is a place for the NIP-05 hints, `nprofile` and `nevent` relay hints and specially relay hints in event tags. All these mechanisms are used together in [ZBD Social](nostr:naddr1qqyxgvek8qmryc3eqyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823chekfst), for example, but I believe also in the clients listed above.
I don't think we should stop here, though. I think there are other ways, perhaps drastically different ways, to approach content propagation and relay discovery. I think manual action by users is underrated and could go a long way if presented in a nice UX (not conceived by people that think users are dumb animals), and who knows what. Reliance on third-parties, hardcoded values, social graph, and specially a mix of multiple approaches, is what Nostr needs to be censorship-resistant and what I hope to see in the future.
