Hacker News Reader

Comment by embedding-shape | Hacker News Reader

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

View on HN

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.

That was you ask exists; it updates through a version counter. It just works on mainline DHT btw.

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

Yes, but it's STUN that sucks. If the software ships with a public (on the internet) relay/STUN server for connecting the two clients, it won't work if either aren't connected to the internet, even though the clients could still be on the same network and reach each other.

/? STUN: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

There is a Native Sockets spec draft that only Chrome implements;

"Direct Sockets API": https://developer.chrome.com/docs/iwa/direct-sockets :

> The Direct Sockets API addresses this limitation by enabling Isolated Web Apps (IWAs) to establish direct TCP and UDP connections without a relay server. With IWAs, thanks to additional security measures—such as strict Content Security Policy (CSP) and cross-origin isolation— this API can be safely exposed.

Though there's UPNP XML, it lacks auth for port forwarding permissions. There's also IPV6.

Similar: "Breaking the QR Limit: The Discovery of a Serverless WebRTC Protocol – Magarcia" https://news.ycombinator.com/item?id=46829296 re: Quick Share, Wi-Fi Direct, Wi-Fi Aware, BLE Beacons, BSSIDs and the Geolocation API

That seems like a nonissue for the purposes of this discussion though, in terms of user uptake. Tiktok and Facebook and other websites aren't exactly focused on serving to people on the same network.

Reply on news.ycombinator.com