I think those events from nip65 are supposed to be spread to as many relays as possible, so you should be able to search in any relays that you want, maybe your own prefered relays. what I do in my app is I have a fixed set of relays that the app uses. But yes this is a problem in Nostr protocol, Nip65 tried to fix and Pubky guys in their protocol solved it by using DHT.
This one, right? https://github.com/nostr-protocol/nips/blob/master/65.md .... ok, but which relay do I ask for this list?
Discussion
Help me understand how a DHT is more effective than a kind 10002 spread to the vast majority of public relays.
Isn't a DHT a similar idea? It is just a bunch of servers that all have more or less the same data stored about how to find the content you are looking for, right?
DHTs are a nice tidy technical solution. It uses math to find the optimal solution for traversing a bunch of nodes. It's really cool, and might work really well for bootstrapping.
DHTs are good at storing an index, but not a massive amount of data (hence pubky's home servers). Nostr relays are great because they give us the ability to scale as much as the web has for both indexes (sub-optimal probably) and data (the only way it's been proven to be possible), while retaining decentralization.
Would it be advantageous for Nostr to move to using a DHT for storing index type information, such as profile information, follow lists, and relay lists, while continuing to store the bulk of notes and other data on relays?
Well, then you need bridges for web apps to get to the DHT. So I don't think a dht should replace outbox, but it could be helpful as a complementary index.
Gotcha. So, not accessible via clearnet without a bridge, and then the bridges would be potential points of failure?
Exactly
No this is not accurate, DHTs aren't "not clearnet" .. browsers are the ones that artificially deny their scripts access to UDP sockets.
But since most users use social media through native apps, and since Web browsers can add support for resolving dns records over the DHT in a weekend (I guarantee it) if they want, I would say this idea that apps can't talk to the DHT through "clearnet" is wrong.
More importantly DHTs are inevitable at scale.
let's imagine the average relay can only supporting 5000 users, ok then you need 1,000,000 relays to support 5 billion users.
So best case scenario, if Nostr is super lucky to have 1,000,000 relay, you still have the problem that clients can't publish to and query from 1,000,000 relays.
So you have to start being clever and shard users over these relays, and now you realise that you need a DHT to do that reliably.
None of this matters though because the stakes of being wrong is too low. If Nostr fail to scale, or it scales and 90 of the 100 popular relays collapse while the remaining 10 have to raise VC money to persist. it won't matter to most.
In fact, already no one cares that these current popular relays are running on grants, and if that dried they will die or persist because the user base dwindled and the expense became lower.
Meanwhile the best bet I can make is that the current millions of DHT nodes will persist even if everyone working on Pubky dies, simply because Bittorrent found product market fit for us. and proved that the economics of the system is sustainable.
Thank you for the more in-depth information. How is Pubkey planning to get around the issue of browsers denying DHT scripts access to UDP sockets? (I have no idea what any of that means, by the way)
Is their solution to only have native apps? Will they run some kind of bridge that web app developers can use? Or will they be trying to convince web browser devs to remove this restriction? Or maybe they will be releasing their own web browser?
I must strongly disagree with the assertion that "most users use social media through native apps."
First, web apps are quite popular on #Nostr, both on desktop and mobile. They also have the advantage of being able to be installed as a PWA, which can particularly help with getting around iOS's appstore and their restriction against zaps.
Second, Nostr is about far more than just social media. Long-form content in, for instance, is much easier interact with and edit in a desktop browser than requiring a native application. Project #Alexandria is another that I can see being popular both as a web app and as a native client.
If you haven't listened, we went in depth on this topic here: https://podcasts.apple.com/us/podcast/nuh/id1694064646?i=1000677472142
Wow! One that I missed! I'll give it a listen. Thanks!
Enjoyed this conversation. A lot of it was way over my head, but I seem to like to torture myself that way.
So, with Pubkey, a user would be signing up through a homeserver, and if that homeserver decided to censor them, they would be SOL and have to start over, just like with Mastodon? Am I understanding that correctly? No posting a note to a few different relays for the sake of censorship resistance via redundancy?
It's been a while, but I believe that's right. Cryptographically signed data is also sort of an afterthought, so there's no smooth path to trustless content replication either.
I caught that, and there was talk about the homeserver signing the content, rather than the user themselves signing their content.