Native implementation of WebRTC

[thomaseizinger]

Are there any plans on natively supporting WebRTC, i.e. without compiling to WASM and running the whole thing in the browser to be able to use js-libp2p-webrtc?

The usecase would be to use WebRTCStar signalling-servers for discovering other nodes. In addition, WebRTC would natively allow nat-traversal, if I am not mistaken.

[Demi-Marie]

Reliable NAT traversal requires a TURN server.

[expenses]

I've looked into this a little bit, and I think that there are a couple of approaches.

A) Generate bindings to google chrome's webrtc library. This library is massive and difficult to build.

B) Write a new webrtc library, using webrtc-sdp and bindings to https://github.com/sctplab/usrsctp. These libraries will get you some of the way there. I am not super familiar with the webrtc spec though, so there might be a lot of complexity still to go.

C) Write bindings to the pion golang webrtc library. This is the library that go-libp2p-webrtc-direct uses. Go doesn't have a great C api, but this approach is possible. I've made a start at binding to go-libp2p-webrtc-direct here.

[backkem]

If you run into any questions regarding WebRTC you may want to check out the Pion channel on the Gopher slack. It contains a vibrant community behind the Go pion/webrtc library. We're open to discussing everything WebRTC, including a Rust port. At this point the Go library encompasses the entire WebRTC spec, including all underlying protocols such as SDP, SCTP, DTLS and ICE. However, it also started by binding to existing C libraries and slowly replacing them.

[Demi-Marie]

I strongly recommend following the same approach Go did: start with binding a C library, but then replacing it over time, with the end goal being a pure-Rust library. I also strongly recommend that we expose a C API compatible with the reference implementation, so that others can use it as a replacement.

[Sean-Der]

All the Pion developers would love to help!

I don't think I will have the time to contribute much code, but would love to document/explain the scary parts of WebRTC :) I think it is super important for WebRTC to have multiple implementations, so feel very strongly that having a rust implementation would be great for everyone!

I have talked to lots of people that want to contribute to a rust implementation, but don't want to lead it. I think the only thing missing is some leadership, and everything else will fall into place. When this gets started I can also evangelize it and get you some contributors hopefully!

[Demi-Marie]

If @tomaka thinks it is a good idea, I would be interested in leading a Rust implementation of WebRTC once I have time, which will likely be once Polkadot launches.

[chengchangwu]

https://github.com/webrtc-rs/webrtc

[paullouisageneau]

Just seeing this now, but datachannel-rs is also a solution. The advantage is that it focuses on WebRTC Data Channels so it's lightweight (no media capture, encoding/decoding, etc)

[wngr]

Just seeing this now, but datachannel-rs is also a solution. The advantage is that it focuses on WebRTC Data Channels so it's lightweight (no media capture, encoding/decoding, etc)

Which I'm using in my prototypical implementation https://github.com/wngr/libp2p-webrtc. To be continued at some point ..

[tomaka]

For what it's worth I also started paritytech/smoldot#1938
The client side works, but the server side isn't done.

It takes the approach of directly establishing the UDP/DTLS/SCTP connection without going through a signalling server or using WebSockets or whatnot, as the point of WebRTC to me is precisely that we don't want to use neither a trusted party nor WebSockets.

[paullouisageneau]

@tomaka Interesting, if I understand correctly you are implementing something like pion/offline-browser-communication. It can work between client and server at the price of security but fundamentally prevents browser to browser connections (because of both ICE checks and DTLS fingerprints).

[tomaka]

Indeed. There doesn't need to be only one way we use WebRTC. The multiaddr can be used to indicate which way we want to use it.