Crate iroh_dht_experiment 

Minimal DHT for iroh

This follows a lot of the design decisions of the bittorrent mainline DHT, with two major differences:

• we use BLAKE3 instead of SHA1, and therefore extend the keyspace to 32 bytes. 32 bytes is also a more natural fit for other purposes such as storage of data for ED25519 keys like in bep_0044
• connections are not raw UDP but iroh connections, with use of 0rtt to make the DHT typical tiny interactions faster.

Other than that this is a pretty straightforward kademlia implementation, using the XOR metric and standard routing tables.

A DHT is two things:

Data storage

A multimap of keys to values, where values are self contained pieces of data that have some way to be verified and have some relationship to the key.

Values should have some kind of expiry mechanism, but they don’t need provenance since they are self-contained.

The storage part of the DHT is basically a standalone tracker, except for the fact that it will reject set requests that are obviously far away from the node id in terms of the DHT metric.

Disabling the latter mechanism would allow a single DHT node to act as a tracker.

Examples of values:

• Provider node ids for a key, where the key is interpreted as a BLAKE3 hash of some data. Expiry is a timestamp, validation is checking that the node has the data by means of a BLAKE3 probe. This is equivalent to the main purpose of mainline outlined in bep_0005.

• A signed message, e.g. a pkarr record, where the key is interpreted as the public key of the signer. Expiry is a timestamp, validation is checking the signature against the public key. Almost identical to bep_0044, except that we don’t have to hash the key because it fits our keyspace.

• Self-contained immutable data, where the key is interpreted as a BLAKE3 hash of the data. Expiry is a timestamp, validation is checking that the data matches the hash. This is also part of bep_0044.

We use postcard on the wire and most likely also on disk.

Routing

A way to find the n most natural locations for a given key. Routing is only concerned with the key, not the value.

DHT nodes talk to each other using a simple rpc protocol. RPC requests can always be answered using purely local information.

A DHT node is controlled using the api protocol, which contains higher level operations that trigger interactions with multiple DHT nodes.

Both protocols are implemented using the irpc crate. As an intro to irpc, see the irpc blog post.

Re-exports

pub use api::ApiClient;

Modules

api

RPC protocol for an user to talk to a DHT node.

config

Detailed configuration for the DHT.

pool

An abstract pool of RpcClients.

rpc

RPC protocol between DHT nodes.

Structs

Config

Dht lookup config

Functions

create_node

Creates a DHT node