talb
March 5, 2021, 9:01am
1
I’m sorry if I’m being too impatient, but when can we expect direct browser-to-browser connections with js-libp2p using Circuit Relay for WebRTC signaling?
Here is the relevant resource:
opened 09:29PM - 21 Jul 19 UTC
closed 06:39AM - 10 May 23 UTC
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
We don’t have a clear timing yet. We are currently working on Project Flare . This project is in progress Project Flare aka. decentralised hole punching by aarshkshah1992 · Pull Request #21 · protocol/web3-dev-team · GitHub and will be the initial step towards that.