logoalt Hacker News

convolvatrontoday at 3:34 PM2 repliesview on HN

I should read the specs, but since it's such a foundational issue maybe someone who knows could respond briefly? the problem with a flat addressing space is that it requires every intermediate node to have state about every address, or perform a costly discovery mechanism for those it doesn't know about. is there a clever answer to this?


Replies

rklaehntoday at 3:44 PM

We have an answer, but it isn't really clever. We do have both built in and pluggable address lookup services.

Our default enabled address lookup service is using DNS in a creative way, but we also have a service that is fully peer to peer and is using the mainline DHT, specifically the bep_0044 extension that allows you to store a tiny bit of arbitrary data for an Ed keypair that you control.

https://www.bittorrent.org/beps/bep_0044.html

https://pkarr.org

Some custom transports such as TOR hidden services have a discovery system built in. In these cases we can just use the existing discovery system.

See for example https://github.com/n0-computer/iroh-tor-transport

matheus23today at 3:40 PM

The secret is that iroh still uses IPs under the hood :) But with QUIC, your connections aren't bound to your four-tuple, your connection can migrate from e.g. WiFi to Cellular with only a small blip/hiccup. And with QUIC multipath, you can have multiple four-tuples "active" at the same time. iroh uses e.g. a "real" IP path mainly, with a websocket-based HTTPS path via relay servers as the backup (e.g. in case UDP is blocked).