alt Hacker NewsI think we still have the same blocker as we had back when WebTorrent first appeared; browsers cannot be real torrent clients and open connections without some initial routing for the discovery, and they cannot open bi-directional unordered connections between two browsers.
If we could say do peer discovery via Bluetooth, and open sockets directly from a browser page, we could in theory have local-first websites running in the browser, that does P2P connections straight between browsers.
Replies
If a tracker could be connected to via WebRTC and had additional STUN functionality, would that suffice? Are there additional WebRTC limitations?
> they cannot open bi-directional unordered connections between two browsers.
Last I checked, DataChannels were bidirectional
Could you run some kind of hybrid DHT where part of it was Webrtc and part was plain HTTP(S) / WebSocket?
There are some nodes (desktop clients with UPNP, dedicated servers) that can accept browser connections. Those nodes could then help you exchange offers/answers to give you connections with the Webrtc-only ones, and those could facilitate offer/answer exchanges with their peers in turn.
It'd be dog-slow compared to the single-udp-packet-in, single-udp-packet-out philosophy of traditional mainline DHT, but I don't see why the idea couldn't work in principle.
I think a much bigger problem is content discovery and update distribution. You can't really do decentralized search because it'd very quickly get sybil-attacked to death. You'd always need some kind of centralized, trusted content index, but not necessarily one hosted on a centralized server. If you could have a reliable way to go from a pubkey to the latest hash signed by that pubkey in a decentralized way, + E.G. a Sqlite extension to get pages on-demand via WebTorrent, that would get you a long way towards solving the problem.