Let’s consider two js-libp2p nodes running on the browser, Bob and Alice.
There are currently 2 WebRTC transports for libp2p:
/p2p-webrtc-star/which allows direct connection between 2 browsers, but that requires a rendez-vous server that nodes connect to using WebSocket and that is run by one of the peers or someone else. Another disadvantage is that both Bob and Alice must connect to the signaling server before the connection. What it means is that if only Bob wants to connect to Alice, it doesn’t work, because Alice is never aware of that.
/p2p-webrtc-direct/that doesn’t need any rendez-vous server or any other entity than the 2 nodes we want to connect. But because it exchanges the WebRTC handshake data (SDP and ICE candidates) in a HTTP request, it only works for browser=>server or server=>server connections.
As we see, as of right now there is no transport for directly connecting two browsers without them relying on a signaling server that adds centralization. Then there is the much hyped circuit relay (URL: docs.libp2p. io/concepts/circuit-relay, new users can only put 2 links) that will hopefully be implemented sometime soon in libp2p. Here is an example of multiaddress using circuit relay:
In a nutshell, circuit relay routes all the communication between the 2 peers in a circuit of nodes of the network. But doing this is a bit overkill, we don’t need the relay all the time with WebRTC, we only need it for the signaling, then we can establish a direct connection between the 2 peers.
So I think we need a third WebRTC transport (let’s name it
/p2p-webrtc-relay/ for the sake of the explanation). It would operate like this for example:
- Bob adds the
- Bob connects to the relay node (Go or Node.js) using WebSocket,
- The relay tries to establish a circuit between Bob and Alice,
- Once a circuit is found, the handshake data is exchanged between the 2 peers (i.e. the SDP and the ICE candidates),
- The direct WebRTC connection between Alice and Bob is finally established and the circuit relay can be dropped.
Of course, this would require first to have a stable implementation of circuit relay, which is not the case right now, but once it is done this would be (I think) the first time a practical way has been found to establish a WebRTC connection between 2 browsers in a truly peer-to-peer manner.
What do you think?