DHT reasoning, philosophy...

[mnqw95]

At the present time, the basis of Yggdrasil is a peer-to-peer DHT distributed table, where the key is IPv6 (200 :: / 300: :) and as the desired value these are the coordinates and the public encryption key)

My suggestion is to embed in the network a few more distributed DHT tables that work in parallel with the main DHT for the best interoperability and system performance.

DHT-Peers Unified database of public nodes. Find nearby nodes by physical location as a key (country, district) as a value a list of IP: Port addresses of public peers. This will give automatic load balancing. and a quick change of coordinates if one of the public peers is out of order.

DHT-DNS The distributed table will use the custom domain (website.ygg, website.yy ... and others) as the key, and the YGG-IPv6 address as the desired value. There are already a lot of similar projects on github: /dhtdns , /dns-via-dht , /bittorrent-dht-dns , and many others

DHT-IPv4 It is completely similar to DHT-DNS, it works the same, only as the required Key there will be virtual ipv4 (10.0.0.0. \ 8 and 100.0.0.0. \ 8) as the Value, the same YGG-IPv6 address. The total number of ipv4 addresses is about 33 million (I think that's enough for everyone) DHT-IPv4 will make it possible to use the ipv4 local address on the pc and facilitate the use of programs that do not work with the IPv6 protocol. In order not to rewrite all the logic, implement an IPv4 = IPv6 converter in the client application, redirect traffic from IPv4 to IPv6 and vice versa. famous implementation example: https://github.com/keiichishima/map646

But for DHT to work flawlessly, you need to use:

1. Good replication (so that when any node is turned off, data does not disappear)
2. Long-term storage (1 year at least)
3. Limited access to change the record, so that only the owner himself, and not someone else can do it.

[neilalexander]

We have discussed DNS in the past in #661, but ultimately we consider DNS to be out of scope for this project, even though it would be nice from a usability perspective.

With regards to automatic peerings, we also consider this to be out of scope (#729, #388). Specifically Yggdrasil is an experiment to see if we can always find efficient routes with the peerings that we have available, not by automatically adding more of them. If we add automatic peering between nodes then we are effectively baking in a dependency on the internet and/or global reachability between nodes.

[mnqw95]

in #661 is a little different than I would like to see. these meshname and other unreadable domains, it is best to initially use regular Ipv6 I propose to embed a full-fledged distributed base with many keys and many values ​​for implementation. This would improve the routing and other functionality of possible DHT-DNS DHT-Peers DHT-IPv4 The list is not complete https://hostingdata.co.uk/nosql-database/ Many databases just use a tree structure, and will fit into the project

[neilalexander]

Closing as out-of-scope.