WebRTC Exploration #20
Comments
|
Probably not very high priority yes. In terms of order of operations, before this there is:
And then WebRTC for Browser to Browser (probably informed by specific user story that Dapp etc have) |
Yes, this is in line with the position it has in the project. Thanks! |
|
Let's start with https://github.com/libp2p/js-libp2p-webrtc-direct as it may help getting rid of ssl certificates on nim-waku side. |
|
WebRTC Direct works in Chrome but not Firefox. There are some issue with Chrome to investigate. |
Opened a PR: libp2p/js-libp2p-webrtc-direct#147 |
|
WebRTC Direct findings:
Next: integrate and test in js-waku |
|
WebRTC Direct is promising as an alternative, out-of-the-box transport protocol for js-waku<>nim-waku: |
|
Linking related upstream issues: |
|
@D4nte just so you are aware that WebRTC Direct isn't being actively pursued on a libp2p protocol level:
|
Indeed. Thanks. WebRTC direct is an interesting protocol because it enables to connect to a server without needing for this server to have a SSL certificate configured. ~It seems that this exact property is what makes WebRTC not a good candidate for libp2p specs as they want the protocol to provide a security layer without adding another (I guess noise). Yet, to negotiate the handhake, information between the browser and server must be exchanged. In libp2p's webrtc-direct, this is not via wss, meaning a certificate setup is needed. What is interesting and not the first time I have heard of it, is the intent for protocol labs/libp2p bootstrap nodes to generates certificates for nodes to fulfill this requirement. In this case, WebRTC Direct is not attractive anymore and something much more efficient such as WebTransport can be used (a kind of evolution of WebSocket). |
Browser-to-Browser WebRTC Exploration findingsNote: This is about WebRTC, browser-to-browser communication. It is different from WebRTC Direct, which is browser-to-server communication. Most comments above are about the exploration of WebRTC Direction Goallibp2p's Browser-to-browser WebRTC needs a signaling server to which both browsers can connect. This is needed to enable the browsers to exchange handshake data to setup the WebRTC connection. The goal of this exploration was to determine whether it would be possible to remove the necessity of a signalling server and instead, use the Waku network to enable two browser to negotiate a WebRTC connection. Result (tl;dr:)
DetailsThe PoCThe PoC was not successful because I tried to take a number of hacky design decision on the fly to just make it work, especially around using Waku as a socket server. Which, at the end of the day, is mostly what a signalling server is. I believe we can be successful in replacing the signalling server with the Waku network if we create few building bricks first. See the last section of this comment. Proof of Code: https://github.com/D4nte/js-libp2p-webrtc-star/tree/transport-waku The Signalling ServerThe WebRTC Star Signalling Server is a socket server (using socket.io) that handles the following events: interface SocketEvents {
'ss-handshake': (offer: HandshakeSignal) => void
'ss-join': (maStr: string) => void
'ss-leave': (maStr: string) => void
'ws-peer': (maStr: string) => void
'ws-handshake': (offer: HandshakeSignal) => void
'error': (err: Error) => void
'listening': () => void
'close': () => void
}Connection Management
Once a peer has joined, the signalling server regularly send the current list of connected peers to it by emitting WebRTC HandshakeA peer connected to the signalling server can initiate a handshake with another peer by emitting a export interface HandshakeSignal {
srcMultiaddr: string
dstMultiaddr: string
intentId: string
signal: Signal
answer?: boolean
err?: string
}The signalling server then does some sanity checks and forward the offer to the right peer ( sequenceDiagram
actor Alice
participant "Signal Server"
actor Bob
Alice->>"Signal Server": `ss-handshake` offer
"Signal Server"-->>Bob: `ws-handshake` offer
Bob->>"Signal Server": `ss-handshake` answer
"Signal Server"-->>Alice: `ws-handshake` answer
Waku Socket ServerMy first approach to replace the signalling server with Waku was to create a Waku Socket Server that provides the same API than a socket server but over Waku: https://github.com/D4nte/js-libp2p-webrtc-star/blob/transport-waku/packages/webrtc-star-transport/src/waku-socket.ts I believe this is where I failed to properly design this on the fly has some considerations around content topics and peer discovery must be made. The signaling server provides the ability for a given peer to communicate with an other peer by peer id. I try to skip this step by doing only working with a 2 peers scenario but it did not work. Action item To enable WebRTC browser-to-browser connection, we must first design and build a protocol to enable two peers to communicate over Waku given their peer id. Once this is done then it should be trivial to use this instead of a signal server for WebRTC handshake. Tracked with #681 WebRTC Star libp2p transportTo integrate WebRTC transport in Waku, it needs to be used with libp2p. For this, it needs to implement the libp2p transport interface: export interface Transport {
/**
* Used to identify the transport
*/
[Symbol.toStringTag]: string
/**
* Used by the isTransport function
*/
[symbol]: true
/**
* Dial a given multiaddr.
*/
dial: (ma: Multiaddr, options: DialOptions) => Promise<Connection>
/**
* Create transport listeners.
*/
createListener: (options: CreateListenerOptions) => Listener
/**
* Takes a list of `Multiaddr`s and returns only valid addresses for the transport
*/
filter: MultiaddrFilter
}The methods of interest are:
Let's review how they are implemented for libp2p-webrtc-star-transport.
|
|
Icing this until #681 is done. |
|
A correction on WebRTC direct. It was previously stated that no ssl certificate is needed for a webrtc direct connection.
Note: WebSocket Secure must be used in a secure context, ie, https. It is not possible to do a clear WebSocket connection within a secure context (https served page). Modern browser failed silently to the user (errors are displayed in console). When doing the test with the environment above, the As this is opposite to what the libp2p folks have stated I have performed the test again, this time:
In this setup, we can see in the console the following error message: Indeed, it attempts to perform an insecure connection So no, webrtc-direct is not a great candidate as it does not enable a connection to a remote node without an SSL certificate being setup... Except if we use a Waku Socket like process where the SDP (signal data payload) is being exchanged over an existing Waku connection, remove the necessity of a wss connection to the target node. E.g.:
sequenceDiagram
participant A as Alice
participant B as Bob
participant C as Carole
A-->>B: WSS Connection
A->>B: SDP over Waku Relay
B->>C: SDP over Waku Relay
C->>B: SDP answer over Waku Relay
B->>A: SDP answer over Waku Relay
A-->>C: WebRTC Connection
However, while an option. This seems to be cumbersome one. It could be explored once handshake over Waku for p2p WebRTC is done. WebTransport looks like a better option to avoid operating having to setup CA signed certificates: https://github.com/libp2p/specs/pull/404/files |
|
As far as services being provided by the service network goes, having an nwaku node with optional letsencrypt certificate seems doable, especially with a concentration of 1:100 or 1:1000. Assuming such a node exist, and there's a way for browser nodes to agree on which node to use (for now), are there any blockers for WebRTC usage in browser for e.g. a direct browser comm protocol? |
@oskarth. AFAIK, there are no blockers to use WebRTC with Waku to enable direct browser-to-browser communication.
Further exploration on 2. is necessary, I'll create an issue to track. |
|
Following up on the example of Noise+WebRTC usage I'd like to post it's progress here: State of the example: work in progress What's done:
What should be done:
Additional reading that explains why |
|
This issue is a bit cluttered and enabled us to learn further about WebRTC. Next steps tracked in #1181 |
Problem
Some application may need a low latency (<100ms) connectivity, see vacp2p/rfc#446.
.e.g games, voice call, video calls.
Solution
WebRTC is a common way to achieve this low latency in a Browser environment. Investigate and add WebRTC support.
Definition of Done
Notes
This may be relevant:
Check out Status how they do things on secure transport file (compact code) and bundle retrieval https://specs.status.im/spec/5#bundle-retrieval
The text was updated successfully, but these errors were encountered: