Implement rendezvous protocol spec #1
Conversation
It's DiscoverOnce and Discover instead of Discover and DiscoverAsync
- instead of returning PeerInfos, return Registration objects in discovery - provide utility functions at module level for peer info discovery
|
@whyrusleeping @vyzo how's this issue doing? i'd be happy to review it thursday. |
|
Review would be nice, I plan to restart work on it soonish -- see the further work comment. |
|
Hey @vyzo – wondering what you have in mind as a path forward here. Is this implementation already 100% compliant with our flashy new Rendezvous spec? |
|
@raulk yes, it's 100% compatible with the spec. It needs rate limiting to emit the |
|
@vyzo — cool. How about we figure out the error case and we merge this in marking it as EXPERIMENTAL? No point keeping it parked in a PR. We can then keep iterating on master. |
|
I also want to work a bit on the stateful client, but we should be able to merge soon. |
|
The federation can wait for the out of package daemon implementation. |
|
I'll work a bit more on it this week. |
|
@vyzo when are you expecting this will be checked in? |
|
soon [TM] |
…egistered records. Default TTL for discovery client increased discovery client now utilizes server cookie for added efficiency
|
Is this in a place to be reviewed/merged @Stebalien @Kubuxu? |
|
For anyone continuing this pull request, please note that the specification had multiple revisions in the meantime. |
Implementation of spec in libp2p/specs#44
Provides Client, Service, and Database for attaching and using rendezvous points in libp2p hosts and the necessary hooks for implementing federated rendezvous daemons out of package.
TBD: