Hacker News Reader

Comment by nmca | Hacker News Reader

I actually wrote a DHT that operated over WebRTC itself with in-band signalling for my undergrad thesis, in the application/js layer. Total PITA, but a ... "good?" learning experience.

View on HN

How could you possible make such a DHT? We live in the world of NATs, especially symmetric NATs, where each mobile phone user gets assigned a random ip:port every time it makes a connection. DHT, on the other hand, needs every node to have a persistent address that can be contacted any time. In other words, with the NATs, a DHT node cannot cache a bunch of peers and contact them later because those peers are no longer available at those addresses, so every time a node re-joins DHT, it needs to restart the bootstrapping process from scratch, from those initial hardcoded bootstrap servers. Effectively this makes this DHT a fully centralized system. WebRTC cannot solve this problem.

DHT doesn't need every node to have a persistent reachable address from every other node directly. It's ok if some have persistent addresses, some can be reachable after NAT traversal or only through other nodes acting as relays.

You have some proportion of power users that are outside NAT and WebRTC (they run a non-browser executable), their addresses can be shared over the network and stored locally. They provide STUN on rejoining, but are not hard-coded.

(Overall, yes this whole thing is a vaguely bad idea. But not totally degenerate / non viable, just not practically worth it.)

If this idea worked in practice, go-ipfs/js-ipfs wouldn't have so severe problems with connectivity.

any links, please?

(Forgive janky thesis-ness) https://bit.ly/2P7w6cq

This paper is really well done. Im interested in seeing what comes of this. Going to spend some more time with it. Looks like you had the initial idea in 2011, ahead of its time. Well done.

Reply on news.ycombinator.com