Feat: gossip extra webrtc underlays #5190
Conversation
|
why not have both ws and wrtc? |
We can, just that from the browser-based-node perspective websocket seems less utilizable because of a number of factors:
The exception to this seemed to be shared web workers in chrome, which also give a warning about how connecting to unsecured ws endpoints is deprecated, but seemed not to enforce this so far, which could be a bug. |
|
the restriction regarding secure contexts for websocket will soon go away with #5187 |
that would be great, but like how is the bee node going to have a domain name? |
|
In general, I'm not sure why there is a need for a specific WebRTC underlays field, or any specific underlays field and not just have the the existing underlay field store the multiaddr. The "repurposing" of this is suitable as the version of the handshake protocol would have to be bumped nonetheless, and all version bumps are breaking - so doing it in the manner proposed in this PR would not preserve any backwards compatibility. |
im not sure i understand your point correctly, and i dont mean to argue, but in general, protobuf3 is backwards compatible as long as you dont change existing fields and their numbers, you can add new fields with higher numbers, as all fields are optional of course this can be solved in many ways, i simply added a new field for simplicity, so the bee node does not need to cherry pick which protocol to use from a mixed bunch, and the browser based node can find what it needs in the new field |
another thing i experienced that might make this approach more feasible, is that when a bee node connects to another bee node on a webrtc address, it uses a different random port than it uses for listening, and this random port is not dialable, so if we start saving these new connectout-only underlays with the advertised connectable overlays, the gossip will get polluted by these unreachable addresses. so for my PR we only save/gossip the webrtc underlays of a peer communicated by it in the handshake, which are dialable (however they might be private addresses in this PR) |
autotls gives you one as long as you're publicly accessible
that's no longer relevant soon. bee will support multiple underlays.
there is, see AutoTLS
that's not needed. AutoTLS handles everything |
will you need to buy a domain for each bee node, or does autoTLS hand out free domain names? |
no, you don't buy anything. you're issued a [peerid].libp2p.direct domain with https |
lat-murmeldjur
force-pushed
the
wrtc_gossip
branch
from
908d4cb to
4230b89
Compare
3 participants
Checklist
Description
This PR attempts to implement SWIP-24 with the difference of using WebRTC instead of Websockets to enable browser based nodes connecting to the swarm network.
It includes an addition to the handshake protocol with added webrtc underlay fields in protobuf, saving the received webrtc underlays for each peer, as well as added webrtc underlay fields per bzzaddress in gossip. For development purposes right now all ipv4 webrtc underlays are attached to handshake / communicated in gossip, however further refinement can be done to filter out private webrtc addresses from the communication, or to restrict the number of communicated webrtc underlays to 1 per node.
It was revealed during testing that upgrading to the latest go-libp2p version is also required for webrtc connections to work so the PR includes go-libp2p version updates as well.
The reason WebRTC seems to be more feasible for browser connections is the fact that secure websocket connections are required when the browser based node is loaded in HTTPS (which is a requirement for service workers that enable displaying swarm hosted websites in a browser based node), however most browsers do not accept untrusted self signed certificates from swarm nodes for tls/ws or wss. WebRTC seems to work better from across different platforms and browsers, not requiring domain based trusted security certificates from each bee node. This enables connecting to webrtc underlays for example from android chrome.