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.

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.

There are multiple ways you connect with people on nostr. By far the most common is that you find an event from a key you haven't seen before. And so that case must have a good solution. The case where you know the person and scan their business card or go to their personal URI is the easy case. I don't like the NIP-65 solution of "spray it everywhere". It requires people to just-so-happen to look for relay lists in the same places, which drives it to be a centralized thing. I really do like the DHT solution. But the bittorrent/mainline/Kademlia DHT handles only ed25519-signed data blobs. I'm starting to think standing up a new DHT using all the security learnings we have at this time from published academic papers (most of them from early 10s when everybody was into it) might be where we are headed. And I would strongly suggest that such a mechanism not be tied to just one cryptosystem, but to support multiple including PQ signature schemes. It is not just the nostr social graph I want to save, it is the flexibility of signature scheme. Sure you can wave your hands and claim quantum computing will never work. I did that about AI and I was wrong.

If you think bootstraping a social media is hard, wait to see how hard it is to bootstrap a DHT, for reference, Hyperswarm with all the funding they may ever need, still have less than 500 nodes after years and years. I would rather just extend mainline, at least to have some sybil resistance splash on me while bootstraping. But I also think the post quantum thing is the only reason why even bother, there has been no advancements on what mainline does, other than in papers, where you can say whatever you want. But in practice, all modern DHTs are inferior to Mainline, or at the very least have no advantage to offset orders of magnitude smaller network. And indeed there is absolutely no evidence whatsoever that post quantum signatures are needed (different from encryption)... so i think we have at least 10 years to bootstrap this extension of Mainline... more likely we have until forever.

This is more directed to @Mike Dilger ☑️ than to you, but I’m replying here to avoid breaking the chain (and it touches on what you said anyway). I was thinking about this tonight and, honestly, my position hasn’t moved much. DHT might be the "end game" (well, there’s no real end game, but you get me), but looking at the current state of Pubky, it feels like anything of the sort is still years away from achieving a Nostr-like multi-client, multi-intent ecosystem. That comparison isn’t entirely fair given how young Pubky is, but on the other hand, it’s not like the bar is set that high when you consider the competition from Big Tech and their unlimited engineering resources. If we try to force DHT, fancy serialisation, complex contracts, etc. onto Nostr right now, we risk alienating the average pleb dev, someone who can maybe, kinda handle WebSockets and JSON if you give them a JavaScript library and a half decent LLM Agent, but who would seriously struggle with more complex, enterprisey architecture, nevermind R&D sruff. I’m not being dismissive of these devs by the way. I’m not the person who’s going to build the next viral Spotify alternative over Nostr, but they might be. I'm not saying DHT R&D shouldn’t be pursued. In fact, I’m very bullish on Pubky and Pkarr. You've also announced your own greenfield R&D work, and I’m genuinely looking forward to seeing what comes of it. But if we’re being realistic, even though Nostr is small in the grand scheme of things, it’s already a large enough ecosystem to warrant a slower pace... Adopting new ideas only once they’ve matured and stabilised. I know that’s not what a lot of devs want to hear, but IMO it’s the right thing to do if we want Nostr to grow. We need to prioritise expansion over exploration. That said, with a bit of imagination, we can keep Nostr working quite well while those newer ideas are being tested. If we move beyond the purist ideal of "one fully decentralised P2P solution that fits all," we’ll see that NIP-05/NIP-65 actually does the job fairly well (even if you, and I admit, even myself, don’t always give it enough credit). We just need to break the problem down a bit. DNS itself needs to be complemented by rDNS which, IMO, is a bit of a dirty workaround... but hey, it works (sorta). WKD works pretty well for PGP alongside traditional keyservers. Clients can and should cache NIP-05, Kind 0, Kind 10002, and other list/set data kinfs. So as long as we have a deterministic way to retrieve this info, I think it’s good enough for now. The main short-term issue is that Gossip, as it stands, isn’t deterministic when all you know is someone’s npub, and, as Nuh puts it, it’s currently working mostly due to a set of coincidences that will fall apart as people get more serious about running their own relays. My opinion on this is: is it really such a big deal if, for now, we have a bunch of index relays syncing with each other? Honestly, as long as index relays are lightweight and it’s easy for someone to run one and join the network (i.e. not Bluesky/AT Protocol levels of complexity), I don’t think it’s a problem. Could it end up like HKP, where most folks rely on just 2 or 3 servers? Absolutely, in fact that’s actually very likely. But this is good enough for now. And once the experimental, fancy, quantum-resistant, DHT-based P2P solution is ready, we can build something like a gateway indexer relay to bridge the legacy world until clients are ready to migrate. So, the TL;DR: I don’t think there’s anything wrong with playing the tortoise in the tortoise and the hare race of distributed social media protocols. The real issue we face today is that the Outbox model isn’t holding up in a world with thousands of personal relays. That’s the problem we should focus on solving now. Let other protocols run ahead with the fancy R&D stuff; we’ll learn from what they build, and later we can catch up and gradually move the majority of users to the fancier stuff. It might not be as exciting for engineers as working on greenfield projects, but it’s hard honest work, serving actual Nostr users.