Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IPFS Project Roadmap

github.com

Post reply on HN
Print view View original

151–154 of 154 posts

Re: IPFS Project Roadmap

#151

Post by pdxww »

nmca wrote: post #118
pdxww wrote: post #110

This is not a roadmap, but rather a wishlist. There is a fundamental problem that IPFS needs to solve first. This problem is called an efficient WebRTC-based DHT. In order to change the web, IPFS needs to become usable in the browsers. Since the backbone of IPFS is DHT, there need to be an efficient UDP-based solution for "DHT in the web". Right now this isn't possible and reasons are not just technical, but politica…

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.

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.

Re: IPFS Project Roadmap

#152

Post by zzzcpan »

pdxww wrote: post #151
nmca wrote: post #118

Earlier quoted context omitted.

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.

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 longe…

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.

Re: IPFS Project Roadmap

#153

Post by nmca »

pdxww wrote: post #151
nmca wrote: post #118

Earlier quoted context omitted.

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.

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 longe…

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.)

Re: IPFS Project Roadmap

#154

Post by pdxww »

nmca wrote: post #153
pdxww wrote: post #151

Earlier quoted context omitted.

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 longe…

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.
Post reply on HN