WebRTC signaling server support

[oskarth]

Problem

For Waku v2 nodes to talk to each other in a web browser, they need to be able to discover each other. This requires a WebRTC signaling server. This would enable use cases such as live audio and video chat.

The current PoC (https://github.com/vacp2p/waku-web-chat/) is using a basic NodeJS signaling server https://github.com/libp2p/js-libp2p-webrtc-star

It'd be useful to have a native Nim implementation, especially since stability in resource restricted environments is useful here.

I believe this does not require implementing the full WebRTC spec, since it is more about allowing these browser nodes to discover each other.

Acceptance criteria

• WebRTC signaling server support
• Can use to support e.g. Waku Web browser
• Works in a deployed and secure environment
• Ideally better stability than existing NodeJS version

[oskarth]

It might also be useful to provide STUN and TURN capability

[dryajov]

It's worth noting that the current WebRTC implementation/setup in js-libp2p relies on an old setup which predates the existence of Relays and Rendezvous services. Relays are a sort of STUN/TURN service that any capable node can advertise and it's used just as any other transport and address pair. Rendezvous nodes can advertise any type of service, including relays, which allows seamless transport and runtime interoperability.

[Menduist]

This will not be added to nim-libp2p, because it's getting deprecated from libp2p anyway

As mentionned by @dryajov, browsers will be able to use Relay over WS to negotiate their webrtc connection.
Relay are WiP: #670

Rendezvous is a discovery mechanism that it's on our roadmap ATM, but any discovery system can be used instead

[mxinden]

In addition to the above, I also want to reference libp2p/specs#220 here, tracking the WebRTC project on the libp2p project level.

[Menduist]

Thanks, I was actually looking for this issue earlier and couldn't find it!