propose: wrap up rendezvous implementation and deployment

[vasco-santos]

No description provided.

[Gozala]

I wonder if slate use case is worth surfacing here.

[vasco-santos]

Slate would be included in the third use case I think.

Once dapps not rely on star servers, they need a way to discover peers on a dapp scope, so all the peers would register on a rendezvou server under a slate namespace and discover the peers that previously registered.

Is there any other use case you have in mind?

[Gozala]

I meant actually mentioning the slate in the 3rd use case as a real use case makes it more obvious than hypothetical one

[vasco-santos]

Yes, that is a good call.

[Gozala]

@vasco-santos do you have any thoughts on how can we enable teams to expand capacity of rendezvous service ? As in how do we ensure that:

1. It is not centralized around PL operated infrastructure.
2. Nodes deployed by collabs do not fragment network, but rather improve it.

I also feel like there is a need to expand on how this is going to be deployed, is rendezvous service going to be provided a by bootstrap nodes ? Or is there going to be yet another list of addresses clients will be configured with to do a rendezvous ?

[vasco-santos]

@vasco-santos do you have any thoughts on how can we enable teams to expand capacity of rendezvous service ? As in how do we ensure that:

It is not centralized around PL operated infrastructure.
Nodes deployed by collabs do not fragment network, but rather improve it.
I also feel like there is a need to expand on how this is going to be deployed, is rendezvous service going to be provided a by bootstrap nodes ? Or is there going to be yet another list of addresses clients will be configured with to do a rendezvous ?

I have some thoughts, but we should advance first with PL infrastructure and monitor performance before making these a community infrastructure. I did these benchmarks: libp2p/js-libp2p-rendezvous#8 (worth checking the last commit as this PR is done on top of the actual implementation)

We will likely need to setup a cluster of rendezvous servers with a load balancer. I created docker images for everything so that PL and the community can easily deploy such servers, but once we decide how we will deploy this we might iterate with more docs and prebuilt infrastructure images.

[Gozala]

I have some thoughts, but we should advance first with PL infrastructure and monitor performance before making these a community infrastructure. I did these benchmarks: libp2p/js-libp2p-rendezvous#8 (worth checking the last commit as this PR is done on top of the actual implementation)

I'm not sure we're talking about the same thing here. I am not asking if PL can subsidize community with rendezvous nodes, but rather interested in defining how community can add their rendezvous node without fragmenting the network (or the rendezvous registry).

[vasco-santos]

Maybe I was not explicit enough. I was mentioning that deploying and orchestrating these rendezvous servers might not be easy, which would be problematic for "how community can add their rendezvous". These will likely have a large amount of requests and we need to understand if they will scale as expected before trying to grow them.

Regarding network fragmentation, we can think about a small protocol extension. We could have rendezvous servers registering on themselves (and others they know) as providing the "rendezvous server service". This would enable libp2p nodes to find all the rendezvous servers in the network. With this, libp2p nodes acting as rendezvous clients can start asking for peers on a given namespace to a subset of these rendezvous server until they have enough.

[Gozala]

Maybe I was not explicit enough. I was mentioning that deploying and orchestrating these rendezvous servers might not be easy, which would be problematic for "how community can add their rendezvous". These will likely have a large amount of requests and we need to understand if they will scale as expected before trying to grow them.

I would like to offer a slightly different perspective than one I think you might be picturing. There is on overlap between the role SSB Pubs play in the network and rendezvous nodes in IPFS. I as far as I know large loads on pubs is not a problem in SSB, because they provide service to elected peers and peers also learn and connect to multiple pubs. This creates a nice, distributed system without much of an orchestration.

I would love if rendezvous was not designed under assumption of several nodes serving all of the network motivated by philanthropy (or worth yet, discovered a way to take advantage of their position), but rather many limited nodes serving the needs of specific groups or us cases motivated by specific cause.

[vasco-santos]

This creates a nice, distributed system without much of an orchestration.

I would love if rendezvous was not designed under assumption of several nodes serving all of the network motivated by philanthropy (or worth yet, discovered a way to take advantage of their position), but rather many limited nodes serving the needs of specific groups or us cases motivated by specific cause.

Yes, I totally agree this with be a really big improvement to the Rendezvous Spec. How should we add this to the proposal? I wonder it really depends on how fast we want to land Rendezvous. If we go with an alternative first, we can iterate on the spec and spend some more time on this

[jacobheun]

Closing this as it is not on our immediate roadmap. We will reopen when this work intersects with our future timelines and priorities.