search

libp2p / docs

Documentation site for the libp2p project.
https://docs.libp2p.io/
Other
60 stars 88 forks source link

feat: rendezvous #259

Closed salmad3 closed 1 year ago

salmad3 commented 1 year ago

Context

Notes

Section this document lives under will become populated with corresponding PRs.

Latest preview

Please view the latest Fleek preview here.

thomaseizinger commented 1 year ago

It would also be valuable to point out that rendezvouz is not used by IPFS and Filecoin (where is it used at all?).

We used it at my old job for a project which I think is still live (that is why I initially wrote the Rust implementation).

nim-libp2p has an implementation but I don't know about any deployments. (cc @Menduist)

The go implementation I linked above is from berty but I heard that is a forked version and thus may not be compatible? (cc @gfanton)

Menduist commented 1 year ago

We currently don't use it, but probably will in the next few months.

I think RendezVous is one of the best "service discovery" method we can have It's also more suited to mobiles & co

I also think it does not has to be centralized: in our implementation, everyone is storing records, and when pulling records from a peer, you will also store them. So sure, you need "centralized bootnodes", exactly like the DHT But once you discovered other peers, you can just exchange SPRs in a decentralized manner.

IMO it's just a different use-case from the DHT. A DHT is very powerful for:

But when you want to find a "group of peers" (for instance for service discovery), you either need to random-walk your way to them, or store every peers of that group under a single ID (which puts them in a very limited amount of nodes). None of which is ideal

Happy to be corrected here :) We'll try to do some simulations in the upcoming months to see if we can get to a fully decentralized rendez-vous giving better perfs than DHT for service discovery.

gfanton commented 1 year ago

We use a fork of an implementation made by https://github.com/vyzo (https://github.com/libp2p/go-libp2p-rendezvous/tree/implement-spec) at Berty, and it has been working well for us. I'm not sure how compatible it is with the nim-libp2p implementation though. The main change we made was to improve the Subscribe method, which allowed us to add MQTT servers for real-time discovery notification.

As @Menduist mentioned, the Rendezvous service is especially useful on mobile devices where applications have short-lived sessions and cannot use the DHT efficiently due to factors such as bootstrap time and discovery latency. We created a multi-discovery system that advertises on both the DHT and the rendezvous to provide a fallback option, but I'm not completely satisfied with it because it relies too much on the rendezvous and doesn't act as a truly decentralized service. Additionally, the DHT is essentially meaningless in this setup because it is hidden by the rendezvous service and uses too much energy on mobile devices.

Happy to be corrected here :) We'll try to do some simulations in the upcoming months to see if we can get to a fully decentralized rendez-vous giving better perfs than DHT for service discovery.

Please keep us in touch, I'm really looking forward to this 😄