Give DHT access to web clients

[RangerMauve]

Not sure if this is the right place to post this, but I think it would be useful if hybrid clients could be used as a way to give web clients access to the DHT.

This would give us a more decentralized alternative to tracker-based peer lookup, and could enable applications that make use of the DHT.

For example, this would remove the need for a WebRTC DHT, and would enable fancy new things like mutable torrents.

This would need two pieces to work: A way to identify hybrid clients with DHT support, and an RPC API of some sort to talk to the hybrid client's DHT node.

[DiegoRBaquero]

The DHT does not have WebRTC offers/answers which is the only way for web clients to communicate between them. Hybrid clients already have DHT access.

But hybrid clients could form the WebRTC offer/answer DHT between them and pass them to web clients, serving as another option to trackers.

[RangerMauve]

That's what I mean, kinda. The hybrid clients could make connections with web clients, and then have some sort of RPC API over that connection to allow web clients to access the DHT through the hybrid client.

I don't think it's enough for them to act as trackers that do the WebRTC signaling since that won't give access to GET/PUT requests over the DHT which is needed for certain applications to work.

[feross]

to allow web clients to access the DHT through the hybrid client

WebRTC-only clients wouldn't gain anything from being able to read/write the DHT. The DHT only contains ip:port pairs for peers and a WebRTC-only client can't connect to that.

It sounds like you're describing something like https://github.com/webtorrent/ut_pex but for WebRTC connections instead of TCP/UDP ones. So, there's no DHT involved. When a WebRTC peer A connects to another WebRTC peer B to download a particular torrent, A could ask B about other WebRTC peers that it is aware of that are also interested in the same torrent. Say that peer B is connected to peer C that A is not aware of. Then B could act as the signaling server (exchanging offers/answers) between A and C so they can directly connect. There's an issue about this here: #1191

Is this along the lines of what you were envisioning?

[RangerMauve]

Yeah! The DHT to me is more of a means to exchange peer information without having one central server and utilizing peers themselves as much as possible.

However, BEP 46 is another motivating factor for having a DHT so that we could support mutable torrents on the web. I'm sure a new BEP could be drafted up to enable mutability through some sort of gossip instead of a DHT though.

[fabiosantoscode]

@RangerMauve ir you're thinking of sending a PR for #1191 @ me and tell me how I can help.

[RangerMauve]

@fabiosantoscode I don't think I'll have bandwidth for working on that any time soon. 😅 I'm too busy with Dat and WebVR stuff.