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

• 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.

Historical IPFS Work

• [x] Sunsetting the *-star protocols: https://github.com/libp2p/js-libp2p/issues/385
• [x] Distributed signaling protocol (removes need for ws-star)
  • initial proposal: https://github.com/libp2p/specs/pull/159
  • early design: https://github.com/libp2p/js-libp2p/issues/385#issuecomment-514300699
• [x] ~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
• [x] modern libp2p specs
  • [ ] https://github.com/libp2p/specs/blob/master/webrtc/webrtc-direct.md (client-server)
  • [ ] https://github.com/libp2p/specs/blob/master/webrtc/webrtc.md (client-client)

External Work

• WebRTC in (Service) Workers
  • [x] Specs allowing Data channels in Workers: https://github.com/w3c/webrtc-pc/issues/230
  • [ ] WebRTC WG at W3C looking for DHT/P2P use cases for webrtc-nv: https://github.com/libp2p/js-libp2p-webrtc-star/issues/177 / https://github.com/w3c/webrtc-nv-use-cases/issues/60
  • [ ] WPT not passing: transfer-datachannel-service-worker.https.html https://wpt.fyi/results/webrtc-extensions?label=experimental&label=master&aligned
• Mozilla:
  • [ ] Bug: Implement the RTCDtlsTransport interface
• Chromium:
  • QUIC DataChannels

References

• Stable transports in browser: https://github.com/ipfs/js-ipfs/issues/1088
• WebRTC and DWeb analysis https://github.com/arewedistributedyet/arewedistributedyet/issues/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 https://github.com/ipfs/kubo/issues/9724