Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing the Central Rendezvous Points for the *-star transports #134

Closed
daviddias opened this issue Nov 28, 2017 · 2 comments
Closed

Removing the Central Rendezvous Points for the *-star transports #134

daviddias opened this issue Nov 28, 2017 · 2 comments
Labels
P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked

Comments

@daviddias
Copy link
Member

daviddias commented Nov 28, 2017

Given that there is bits of discussion scattered over multiple discussions and we see more people joining the conversation and getting the same questions, it became clear that we needed an issue to track this goal.

tl;dr; libp2p doesn't need central rendezvous points by design, the existing ones were created to facilitate and enable certain transports to exist quickly while the remaining building blocks. If you use webrtc-star or websocket-star today, you will get the Relay or Signalling happening through Circuit Relay once it is fully ready.

Context

We have two transports, webrtc-star and websocket-star that use a central rendezvous point to facilitate the Signaling or Relay respectively so that peers can communicate. It also gives Peers another feature, a pseudo MulticastDNS of the Web, enabling peers to find each other quickly.

This is a normal design used in Video/Audio and/or client-server chat applications, it enables communication to happen fast and makes discovery easy. In fact, for Video/Audio applications, the Relay endpoint is sometimes necessary just to offload the video streaming processing from users machines to fast servers so that the quality doesn't get degraded.

We created the first central rendezvous point for webrtc-star last year before the Decentralized Web Summit, so that applications like orbit-chat could dial to other peers easily since Circuit Relay was still not available as a channel to do Signalling for WebRTC. It was a temporary solution but as in anything, temporary solutions tend to stay for a bit longer than expected.

Today we have a very close to ship implementation of Circuit Relay that is interopable between both implementation, however the community found that there was space and need for another transport that was less memory hungry than WebRTC and decided to create websocket-star. websocket-star is just like Circuit Relay but as a transport and it uses always the same centralized rendezvous point. You can use both today, but that is not the final destination.

After Circuit Relay is fully shipped, the last piece to remove the centralized rendezvous point is solving how module loading happens in libp2p. We need a way to give a libp2p transport the ability to use libp2p itself to establish connections. It is possible to achieve that today, but not without wrangling wires :)

We are confident that by changing how deps are loaded in each of the deps of libp2p itself, we will continue to have the independent and modular structure we known and love, but also enable more use cases to exist instead of one off integrations.

I gave an explanation of this during the IPFS All Hands Call Nov 27 -- ipfs/team-mgmt#528 -- and I hope that this issue clarifies any outstanding question. Thank you! :)

@daviddias daviddias added the P1 High: Likely tackled by core team if no one steps up label Nov 28, 2017
@daviddias daviddias added the status/ready Ready to be worked label Feb 5, 2018
@daviddias daviddias mentioned this issue Feb 5, 2018
13 tasks
@mkg20001
Copy link
Member

ws-star is soon going to be replaced by the rendezvous protocol, so this can almost be ticked as complete.

webrtc-star is being rewritten to be more decentralized libp2p/js-libp2p-webrtc-star#148 using interface-data-exchange. Thoughts?

@achingbrain
Copy link
Member

Closing because circuit-relay-v2 + https://github.com/little-bear-labs/js-libp2p-webrtc will accomplish this!

maschad added a commit to maschad/js-libp2p that referenced this issue Jun 21, 2023
…2p#134)

* fix: added peer connection state listener to emit closed events

* fix: updated listening event name for disconnect/closed events (libp2p#138)

* fix: removed listener once connection is closed (libp2p#138)

* fix: removed listener once connection is closed (libp2p#138)
maschad pushed a commit to maschad/js-libp2p that referenced this issue Jun 21, 2023
achingbrain pushed a commit that referenced this issue Jun 27, 2023
## [6.0.5](libp2p/js-libp2p-pubsub@v6.0.4...v6.0.5) (2023-04-03)

### Bug Fixes

* update project config ([5c7e7f9](libp2p/js-libp2p-pubsub@5c7e7f9))

### Trivial Changes

* Update .github/workflows/semantic-pull-request.yml [skip ci] ([b1c5590](libp2p/js-libp2p-pubsub@b1c5590))
* Update .github/workflows/semantic-pull-request.yml [skip ci] ([f83a2f7](libp2p/js-libp2p-pubsub@f83a2f7))

### Dependencies

* bump it-length-prefixed from 8.x to 9.x ([#134](libp2p/js-libp2p-pubsub#134)) ([ae3e688](libp2p/js-libp2p-pubsub@ae3e688))
* bump it-pipe from 2.0.5 to 3.0.0 ([#133](libp2p/js-libp2p-pubsub#133)) ([cafd733](libp2p/js-libp2p-pubsub@cafd733))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests

3 participants