3 ms·
>> "This document does not specifiy the properties of the underlying distributed hash table (DHT) which is required by any GNS implementation." > Well they do
by espadrine 6y ago
>> "This document does not specifiy the properties of the underlying distributed hash table (DHT) which is required by any GNS implementation."
> Well they do specify the interfaces, why should they care about the impliementation?
The choice of DHT typically has protocolar implications, such as the use of XOR metric in Kademlia, or the bootstrap algorithm.
All nodes must use the same DHT.
As a result, this cannot be implemented without knowing the particular DHT in use.
Furthermore, different DHTs have distinct properties, including provisions for fault tolerance, resource recovery, latency bounds, and byzantine tolerance, which here seems like a concern.
- some-username 6y agoYes, sure. But that's fine - everyone who wants to have their GNS can design their own DHT. It's still outside of the spec. (Which makes a lot of sense to me.)
- jaekash 6y ago> The choice of DHT typically has protocolar implications, such as the use of XOR metric in Kademlia, or the bootstrap algorithm. > Furthermore, different DHTs have distinct properties, including provisions for fault tolerance, resource recovery, latency bounds, and byzantine tolerance, which here seems like a concern. What in the RFC is dependent or contingent on those? from what I read in it none of those properties affect what is specified in the draft. > All nodes must use the same DHT. As a result, this cannot be implemented without knowing the particular DHT in use. Not according to the draft. Sure, if a zone uses a specific DHT and then other nodes not using the same DHT they won't be able to resolve addresses from that zones, but everything in this draft would still be valid.