Replying to Avatar Braydon Fuller

Thinking more about a DHT for querying NIP-65 relay list metadata and had an idea. It could be possible to instead have a DHT-like protocol for relays for querying relay list meta data, where if the relay itself doesn't have it, it could ask their neighbors if they have it, and so on with a max hop count. However, rather than it being distributed by hash, it would be distributed by social connection and a web-of-trust.
Avatar
Braydon Fuller 1y ago

nostr:nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgpypmhxue69uhkx6r0wf6hxtndd94k2erfd3nk2u3wvdhk6w35xs6z7qgwwaehxw309ahx7uewd3hkctcpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7a0nq40 are you familiar with DHTs and do you have any thoughts here? Otherwise it seems like it may become necessary to keep a list of all possible known relays and ask every one if they have a kind 10002 and kind 0 for a pubkey.

Reply to this note

Please Login to reply.

Discussion

Avatar
Mike Dilger ☑️ 1y ago

Yes I think a DHT would be a good solution. I'd prefer an existing DHT implementation since they can be somewhat complex, and not a new DHT-like social graph. The key would be the person's pubkey (or even a hash of that to make it smaller and make it work with an existing DHT implementation).

I haven't done any work on this.

Avatar
Braydon Fuller 1y ago

Cool. I've worked with DHTs before and some of the security issues like eclipse and sybil attacks might be mitigated with a topology that is based on a web-of-trust, rather than by pubkey hash. It may end up being worthwhile to research, for that reason. I would need to take another look at DHT implementations to see how they have mitigated those issues. From my understanding, because of those vulnerabilities, there is somewhat limited utility in a DHT.