Nostr is in a weird place, because the Outbox model works thanks to the adhoc gossip that relies on coincidences to find user outbox relay... but that becomes harder when you give up on scale and start using hundreds of small relays.
But even then, people will figure it out with off-protocol ways to find their friends relays.
They funny part is that, if you give up on large worlds... then are you really getting much better experience than say Pkarr + Email? I claim no, Nostr api is clearly designed for search on big relays... if you give up on that, then might as well rethink the whole api and stack.
Hell, I would rather create a DHT for Secp if the social graph is that irreplaceable... but then use a different backend and api that wasn't designed for the opposite situation we end up at. Gmail offers tons of free storage... we can do stuff with that.
Login to reply
Replies (1)
Agreed. It's a problem, but one with about a gazillion possible solutions. I like the idea of Pkarr / Mainline / DHT.
Other folks are working on variations of the “big indexing relay” approach (not my particular cup of tea, but it's a pragmatic solution, as much as any). We're still a long way from the point where a couple of "indexer" relays aren't enough to store a reasonably recent copy of everyone's Kind 0, 10002, and maybe a few other lists.
I've also bothered poor @Mike Dilger ☑️ a few times about the whole NIP-05 / Kind 10002 chicken-and-egg bootstrapping issue. Well-known URIs should be enough to bootstrap the Nostr experience, WKD style (if I know someone's NIP-05, I should know how to find their stuff). Search would still require centralised relays, of course, but clients wouldn't need to be this complicated.