web3-dev-team
web3-dev-team copied to clipboard
protocol
Proposal: Distributed signaling
@Gozala I think what you're thinking of here is already covered in #21 -- Project Flare, much of which has already been implemented.
@Gozala I think what you're thinking of here is already covered in #21 -- Project Flare, much of which has already been implemented.
I don't believe that is the case, e.g. WebRTC requires signalling server and NAT hole punching isn't going to address that. Today you need to configure node with an address of a signaling server, which is a problem because ethier:
- We configure nodes so they all dial same address which
- Introduces central point of failure
- Challengers our ability to handle all the traffic it will create.
- We continue telling users to configure their nodes to use their own infrastructure which:
- Adds complexity when building products
- Fragments network around signalling hosts
Ideally we could grow signaling infrastructure and make it possible for nodes to discover new signaling nodes as they join the network.
@raulk Am I misunderstanding Project Flare, or does my comment above makes the difference more clear ?
I did closer review of Project Flare #21 and I think while there is a bit of overlap there it does not directly address the problems this proposal is aimed at. More specifically in WebRTC creating a RTCPeerConnection requires URLs for iceServers at the moment (unless I'm mistaken) it is pulled from the node configuration. Which implies that we either centralize & increase load on specific servers or we fragment the network.
Desire here is to change that such that
- Nodes do not need to be configured (With list of ICE candidates)
- Allow nodes to discover available ICE candidates
- Allow other teams building on products to bring new ICE candidates to the network (as opposed to configuring own nodes to use separate infrastructure).
I focused on WebRTC here, but that is also the case with bootstrap nodes and more
@Gozala I see. It wasn't clear this proposal is WebRTC focused.
- Nodes do not need to be configured (With list of ICE candidates) AFAIK, nodes don't need to be configured with ICE candidates, they discover their own candidates with the assistance of ICE servers, right?
- Allow nodes to discover available ICE candidates Did you mean to say "ICE servers"? ICE already handles candidate discovery...
- Allow other teams building on products to bring new ICE candidates to the network (as opposed to configuring own nodes to use separate infrastructure).
Same. You mean "ICE servers"?
Basically this proposal aims to create a decentralised fabric of ICE servers for WebRTC nodes to rely on?
Basically this proposal aims to create a decentralised fabric of ICE servers for WebRTC nodes to rely on?
No that was just an example. I think it is broader than that. E.g. we also configure nodes with addresses for boostrap nodes, if those nodes were to become unreachable by part (or worth whole) of the network they would not be able to recover without reconfiguring nodes, release of new version of products etc... Here solution would be to make nodes remember dialable nodes so they could be used when boostrap nodes can’t be dialed.
Broadly speaking we tell our collabs to configure nodes with addresses to their servers. I think that is harmful for the ecosystem and I’d like to figure out a way that would allow us to change our messaging from “configure your nodes to talk to your servers” to “spin additional nodes to ensure that network is reliable for your users”.
This draft is clearly needs more work to clarify all that.
@Gozala correct me if I am wrong, as far as I understand the goal here would be to assign roles to nodes and advertise these roles in the network. For instance, you would have a set of libp2p nodes which would be "ICE servers". These nodes would advertise (via DHT, Rendezvous, ..) that they have such a role and peers in the network can find these advertisements.
Considering the above, I think that this could be part of the Limited Relay work described in Project Flare. Ideally any node acting as a limited relay should be able to enable two peers with webRTC to exchange SDP offers, instead of having a special implementation of a relay to do this. As we are going to implement a new version of the circuit protocol, it would be good to also have in mind WebRTC signalling.
No that was just an example. I think it is broader than that. E.g. we also configure nodes with addresses for boostrap nodes, if those nodes were to become unreachable by part (or worth whole) of the network they would not be able to recover without reconfiguring nodes, release of new version of products etc... Here solution would be to make nodes remember dialable nodes so they could be used when boostrap nodes can’t be dialed.
This is not the case anymore since we have a persisted PeerStore. We will try to connect to the configured bootstrap nodes + all previously known nodes (within the connectionManager thresholds).
What we really need to do here (at least in JS) is creating an intelligent way of doing follow up dials on restart:
- If we already know a lot of peers, why connect back to the boostrap nodes?
- If peer X is (in theory) not valuable to us why connect to it?
- for example, if a given node has pubsub enabled, it would benefit from connection to peers that also run pubsub instead of the DHT
https://github.com/libp2p/js-libp2p/issues/744 check the proactive dial part in this issue
@Gozala correct me if I am wrong, as far as I understand the goal here would be to assign roles to nodes and advertise these roles in the network. For instance, you would have a set of libp2p nodes which would be "ICE servers". These nodes would advertise (via DHT, Rendezvous, ..) that they have such a role and peers in the network can find these advertisements.
I think this is a great way to put it, thanks! I also think there will be roles beyond "ICE", e.g me and @hugomrdias talked about "IPNS record keepers" as one such a role.