Skip to content

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

Closed
@daviddias

Description

@daviddias

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! :)

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High: Likely tackled by core team if no one steps upstatus/readyReady to be worked

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions