Discv5 interest?

[AgeManning]

I have a working version of discovery v5 in https://github.com/sigp/rust-libp2p/tree/discv5

It currently functions as a standalone protocol integrated with libp2p for our particular use case.

Discv5 is still a work in progress, so future versions still needs to be built.

To fit with rust-libp2p, it still needs to upgrade to stable futures and remove tokio in favour of async-std. I'm deciding whether to take this and merge it into our project and maintain it there. However there are some others interested in this, in which case it may be suited to this repo.

Is there any interest in adding the discv5 protocol to rust-libp2p? If so, I may do the work to make it suitable for rust-libp2p.

[burdges]

We've some DHT based discovery scheme already, no? How do they differ?

At least for polkadot, we should replace SECIO and sep256k1 with TLS 1.3 or Noise, while this appear fairly wedded to them, but this is more about keeping people on the same code bas I guess.

cc @decanus @oskarth @infinity0

[mxinden]

We've some DHT based discovery scheme already, no?

@burdges yes, Substrate and thereby Polkadot use random walks on a Kademlia Dht to discover new nodes.

How do they differ?

Referencing the Why are we using discv5 and not libp2p Kademlia DHT? from the eth2.0 specification.

[tomaka]

Is there any interest in adding the discv5 protocol to rust-libp2p? If so, I may do the work to make it suitable for rust-libp2p.

It's a good question.
Similarly in Substrate we're considering doing some additional UDP pinging as a temporary measure, and the same question arises.

All the protocols in the rust-libp2p repo right now operate within a "libp2p connection" (encrypted/multiplexed on top of a transport), except for libp2p-mdns, which belongs here because it's part of the libp2p specs.
If I'm not mistaken, discv5 would also not use libp2p connections but plain UDP.

I'm thus inclined towards "no, it should be in another repo".
Looking at your code, if I'm not mistaken you only need to be pluggable to rust-libp2p for the NetworkBehaviour::addresses_of_peer and NetworkBehaviour::poll method.
I suppose we could add some helpers in rust-libp2p to make that easier to plug in.

(edit: I also don't have a strong opinion on this)

[decanus]

If I'm not mistaken, discv5 would also not use libp2p connections but plain UDP.

Yeah that is correct, I remember reading the specification for discv5 and libp2p in eth2.0, and it seemed pretty janky due to that exact reason.

[AgeManning]

Yes. Discv5 uses udp and my implementation behaves very similarly to libp2p-mdns, in the sense that it doesn't use any currently established transport or upgraded connection.
It has its own encryption layer and peer identification scheme.
When I started, I thought it would be nice to have an addition protocol in libp2p however as it developed it couldn't fit into the standard libp2p structure as a transport with upgrades.

I've built essentially wrappers around the protocol so that it interfaces with libp2p for my specific purposes (as @tomaka noticed in the behaviour). I think also that primary users of this may not be using libp2p and it probably makes more sense then to make it stand-alone.

There is still the option to import it as a standalone crate and use similarly to mdns (with added libp2p wrappers) however I think this is not worth the effort if there are no other specific projects that require discv5 within libp2p.

I'll close this and convert it to a stand-alone crate.

Thanks for the comments :)