feat: rendezvous protocol initial implementation

[vasco-santos]

This PR adds the rendezvous protocol server implementation using the latest js-libp2p.

Spec: https://github.com/libp2p/specs/tree/master/rendezvous

This PR contains the server implementations, as well as some hardening and performance considerations. Take into account that this was a full rewrite of the module, so you do not need to have into account the older code.

Github actions CI only allows services to operate in linux. Other environments are not being used

[vasco-santos]

@jacobheun this should be ready for an initial review on the structure, API and rpc parts. I also left a few questions that would like to discuss ( @vyzo would like your feedback on them as well)

[jacobheun]

Added some initial comments.

One thing I think would be valuable here is to write a separate readme on how this will work with js-libp2p, as I think that will help flush out the API here a bit better. Assume we have a single rendezvous server, a relay, and a few nodes who want to find one another on a certain namespace. libp2p should start by connecting to the rendezvous server and ask for nodes in the relay space (if they aren't dialable) so that they can add that as a listener. The nodes should also query for peers they want to connect to on the same namespace. Once a node as a dialable address (relay or otherwise), it should register on its target namespace.

We should consider what the responsibilities are internally for libp2p and what they are for the application.

• Who is responsible for querying in the first place? Does libp2p handle this, or does the application need to account for it?
• After a query is made, who is responsible for determining if we need more records? (cookie reuse)
• Who is responsible for unregistering? Does libp2p do this on shutdown?

I think the use cases may vary quite a bit so it's reasonable for application logic to handle a lot of this, but clarifying that in usage guides and showcasing how to do those things is valuable and will make sure we've provided the support to do that.

[vasco-santos]

Github actions does not support running services (mysql) when running tests on other OS... We can move into travis, but I feel we can just run it in ubuntu as I don't expect people will run a Rendezvous server in Windows/MacOS

[vasco-santos]

I kept the memory datastore previously implemented in the repo. It might be useful for small tests without spinning up MySQL, as well as to run the tests in the browser.

The browser tests are not useful as no one should run this in the browser, and I can remove them.

For example, for testing the libp2p client in libp2p core, it is easier to use the memory datastore, in order to not have to spin a MySQL db for running the tests

[vasco-santos]

libp2p/specs#302

[carsonfarmer]

How likely is this to be merged any time soon? Looking really good!

[vasco-santos]

How likely is this to be merged any time soon? Looking really good!

Thanks for reaching out. Apologies for the lack of visibility on the state of this. This is currently blocked on a couple of things:

• Message signing Rendezvous message signing specs#303
• Get benchmarking like chore: add benchmarks #8 to a more reliable scenario using testground (js sdk is in development)
• Reviews/Deployments

It will likely not happen in the near future, unless we have more specific requirements from the community that push this work. The priority for this is being tracked in this project PR: protocol/web3-dev-team#67

[vasco-santos]

As a status update on the Rendezvous Protocol, there is a new breaking change to the protocol that needs to be accounted for this PR libp2p/specs#338