New WebRTC transport?

talb · January 27, 2020, 7:45pm

Ok I now have the answer, decentralizing WebRTC signaling is already a WIP for js-libp2p:

github.com/libp2p/specs

Add WebRTC Signaling Protocol Spec

master ← 0xProject:webrtc-signal-protocol

opened 11:59PM - 22 Mar 19 UTC

albrow

+218 -0

## Summary This PR introduces a draft specification for a WebRTC Signaling Pr…otocol which can be used to establish a WebRTC connection between two peers. At this time, the specification should be considered a work in progress. There are still some details to work out regarding signatures, message encoding, and error handling. ## Additional Context I know that there already has been some work done to add WebRTC support in the JavaScript implementation of libp2p (see [js-libp2p-webrtc-direct](https://github.com/libp2p/js-libp2p-webrtc-direct) and [js-libp2p-webrtc-star](https://github.com/libp2p/js-libp2p-webrtc-star)) and there is also a community-contributed WebRTC transport for the Go implementation (see [backkem/go-libp2p-webrtc-direct](https://github.com/backkem/go-libp2p-webrtc-direct)). However, AFAIK we do not yet have an agreed upon standard for establishing WebRTC connections. The goal of this proposal is to have a single standard that can be used across all language implementations and is compatible with both non-browser peers (which have the ability to serve as the signaler themselves) and browser peers (which must rely on a third-party signaler).

github.com/ipfs/in-web-browsers

Enabling WebRTC Transport in Browser

opened 01:44PM - 08 Oct 19 UTC

lidel

epic

> 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](https://github.com/libp2p/go-libp2p-webrtc-direct) / [js-libp2p-webrtc-direct](https://github.com/libp2p/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](https://github.com/libp2p/go-libp2p-webrtc-direct/tree/master/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](https://www.w3.org/TR/webrtc/#dom-rtcdtlstransport-getremotecertificates) could in theory let webrtc handle encryption & stream muxing in the browser. Unfortunately it is [not supported by Firefox](https://caniuse.com/#search=getRemoteCertificates).. [yet](https://bugzilla.mozilla.org/show_bug.cgi?id=1307996). ### 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](https://github.com/libp2p/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](https://bugzilla.mozilla.org/show_bug.cgi?id=1307996) - Chromium: - [QUIC DataChannels](https://github.com/arewedistributedyet/arewedistributedyet/issues/30) ### 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

github.com/libp2p/js-libp2p

It's (beyond) time to sunset the *-star protocols 🌅

opened 09:29PM - 21 Jul 19 UTC

closed 06:39AM - 10 May 23 UTC

daviddias

Long story short for context: - Back in 2016, we created two shortcuts to ena…ble js-ipfs to connect to other Browsers quickly, these were: https://www.npmjs.com/package/libp2p-webrtc-star & https://www.npmjs.com/package/libp2p-websocket-star. - The star in the name comes from the fact that what they were doing was a [pure mesh in which everyone listening to on that transport, would dial to everyone else in that transport](https://proxy.duckduckgo.com/iu/?u=https%3A%2F%2Ftse1.mm.bing.net%2Fth%3Fid%3DOIP.NFHkeYFHOABxVk8E1VvuogHaGq%26pid%3DApi&f=1). - These were created in a time where there was no circuit-relay, delegated routing and dht implementation. - These were never designed to be long term solutions, in fact, they were designed to be quick tools for demos. They have design flaws and worse, they end up re-implementing a lot of what libp2p already does (connection authentication, peer discovery, circuit-relay and rendezvous) ## Proposal: `Let's sunset the *-star protocols 🌅` ### To clarify: - A) https://github.com/libp2p/js-libp2p-websocket-star && https://github.com/libp2p/js-libp2p-websocket-stardust are equivalent to listening in a circuit-relay address for dialing, and rendezvous protocol for discovering - B) https://github.com/libp2p/js-libp2p-websocket-star-multi is equivalent to listening in multiple circuit-relay addresses - C) https://github.com/libp2p/js-libp2p-webrtc-star/ is the same as A), but uses that connection to establish a WebRTC connection (SDP exchange) ### Direct benefits: - By cutting of the *-star transports, we would be saving the time from reinventing the wheel and also reduce the confusion from the users. - Any IPFS node could then be the rendezvous or the relaying address (meaning that we can use the go-libp2p to handle with even more clients). More - We avoid spending time creating custom instrumentation and use instead the instrumentation that IPFS & libp2p have. - Any security, perf improvement or memory leak fix will be directly on libp2p and/or IPFS rather than external "temporary" code. - People would not have to rely on a centralized of custom built infrastructure, instead, they could use it with any IPFS node. ### Candidate Roadmap: - **Milestone 1: Sunset any variation of the websocket-star (star, stardust, multi, and so on)** - [ ] Verify that https://github.com/libp2p/js-libp2p-rendezvous is complete and well tested - [ ] Remove any trace of *-star transport from js-libp2p (examples, docs) - [ ] Remove any trace of *-star transport from js-ipfs (examples, docs, base config) - [ ] Upgrade PeerPad to use rendezvous & circuit-relay to find other peers (dropping webrtc-star) - [ ] Make it default with js-ipfs - **Milestone 2: Sunset webrtc-star (easier, if the above is done first)** - [ ] Create webrtc-circuit-relay-exchange (for lack of better name for now) that uses the Circuit Relay to exchange the SDP offer. - [ ] Test it with PeerPad - [ ] Make it default on js-ipfs

The only question remaining is, when will we have a stable implementation of it?

Topic		Replies	Views
New transport: go-libp2p-webrtc-direct News and announcements	1	962	April 2, 2019
WebRTC transports and multiaddrs js	2	852	January 7, 2020
Browser-to-browser connections? js	2	1301	August 26, 2019
PubSub to connect browsers js	2	2622	January 27, 2020
Does js-libp2p-webrtc-direct work behind NAT	1	528	April 19, 2021

New WebRTC transport?

Related topics