mikedilger on Nostr: In my opinion: The DHT backend of PKARR is useful and I would suggest it for nostr ...
In my opinion:
The DHT backend of PKARR is useful and I would suggest it for nostr except for a few problems
1. It breaks the rule of only one way of doing something,
2. DHT interface code is not "simple" like the rest of nostr is
3. There might not be many libraries to use for DHT interface code.
As for PKARR itself, the DNS part doesn't help us, and in fact complicates things quite a lot. I understand why pubky wants it and likes it (they are using pubkeys as websites, and browsers already look up in DNS), but for nostr we should bypass that part if we were to use mainline DHT.
The fundamental purpose of kind 10002 (declaring a person's relays) remains necessary and PKARR does not change this. The "gossip model" doesn't go away, it just may have a different way of bootstrapping (e.g. instead of searching on popular relays for the 10002 event, you look up the data in Mainline DHT).
BTW: This was already implemented and working in Mosaic (which is idle).
The DHT backend of PKARR is useful and I would suggest it for nostr except for a few problems
1. It breaks the rule of only one way of doing something,
2. DHT interface code is not "simple" like the rest of nostr is
3. There might not be many libraries to use for DHT interface code.
As for PKARR itself, the DNS part doesn't help us, and in fact complicates things quite a lot. I understand why pubky wants it and likes it (they are using pubkeys as websites, and browsers already look up in DNS), but for nostr we should bypass that part if we were to use mainline DHT.
The fundamental purpose of kind 10002 (declaring a person's relays) remains necessary and PKARR does not change this. The "gossip model" doesn't go away, it just may have a different way of bootstrapping (e.g. instead of searching on popular relays for the 10002 event, you look up the data in Mainline DHT).
BTW: This was already implemented and working in Mosaic (which is idle).