Enabling WebRTC Transport in Browser

[lidel]

This issue tracks what needs to happen before we enable WebRTC transport in JS-IPFS by default. It also acts as an entry point to existing resources in other repos.

Current Status

• js-libp2p-webrtc-star - libp2p WebRTC transport that includes a discovery mechanism provided by the signalling-star

  • caveat: opt-in, JS-only, centralized signaling service is a single point of failure

• go-libp2p-webrtc-direct / js-libp2p-webrtc-direct - A libp2p transport that enables browser-to-server, and server-to-server, direct communication over WebRTC without requiring signalling servers (examples)

  • caveat: opt-in, point-to-point over http, no browser-browser

Goals

• Transport that does not require hardcoding centralized signaling server to work and is stable enough to be enabled by default in JS IPFS.

• RTCDtlsTransport API: getRemoteCertificates could in theory let webrtc handle encryption & stream muxing in the browser. Unfortunately it is not supported by Firefox.. yet.

Ongoing IPFS Work

• Sunsetting the *-star protocols: It's (beyond) time to sunset the *-star protocols 🌅 libp2p/js-libp2p#385
• Distributed signaling protocol (removes need for ws-star)
  • initial proposal: Add WebRTC Signaling Protocol Spec libp2p/specs#159
  • early design: It's (beyond) time to sunset the *-star protocols 🌅 libp2p/js-libp2p#385 (comment)

External Work

• WebRTC WG at W3C looking for DHT/P2P use cases for webrtc-nv: PSA: WebRTC WG at W3C looking for DHT/P2P use cases libp2p/js-libp2p-webrtc-star#177
• Mozilla:
  • Bug: Implement the RTCDtlsTransport interface
• Chromium:
  • QUIC DataChannels

References

• Stable transports in browser: Stable transports in the browser js-ipfs#1088
• WebRTC and DWeb analysis WebRTC arewedistributedyet/arewedistributedyet#7
• https://w3c.github.io/webrtc-pc/#peer-to-peer-connections
• https://caniuse.com/#search=getRemoteCertificates

[mitra42]

Maybe I missed it, but did you fix the problems that made webRTC not work before - if I remember correctly (and its possible I don't) it was a problem with JS-IPFS needing lots of connections and webRTC having very high per-connection overhead.

[lidel]

I believe it should be partially addressed: js-ipfs added support for libp2p's ConnectionManager, which enables us to set limits on the number of connections maintained by js-ipfs. AFAIK we are still lacking primitives for controlling the number of connections per transport.

[backkem]

Why do you need getRemoteCertificates? Can't PeerConnection handle both stream muxing and encryption:

• stream muxing: Just open multiple Data Channels.
• encryption: Everything is sent over DTLS. The certificates are inherently verified by the signaling.
  • Is there a need to manually verify? You could do this against the fingerprint in the SessionDescription.
  • Or is there actually a need to extract the remote certificate? Knowing the the security is dealt with end-to-end by WebRTC already.

[lidel]

Work towards enabling WebRTC transport in Kubo is planned/tracked in ipfs/kubo#9724