search

libp2p / rust-libp2p

The Rust Implementation of the libp2p networking stack.
https://libp2p.io
MIT License
4.61k stars 959 forks source link

Allow custom protocol Id for all protocols #1115

Closed AgeManning closed 5 years ago

AgeManning commented 5 years ago

It has been suggested that applications use their own protocol id's as a fundamental segregation of networks between different applications.

Recently, a go application using libp2p failed as it became interconnected with ipfs nodes because somehow the nodes got on the discovery protocol and the two applications where using the same protocol id.

I suggest a PR (which i'm happy to write) that allows each protocol's id to be customized. This, however would not be backwards compatible (as far as I can tell). I'd likely add the option to the behaviour struct upon initialization.

AgeManning commented 5 years ago

In particular, I'm referring to this: https://github.com/ethereum/eth2.0-specs/pull/935#discussion_r280413163

tomaka commented 5 years ago

I'm not against making that change, but I thought that libp2p was all about interoperability. If suddenly every network has their own protocol in order to prevent them from talking to each other, I'm confused about the point of having protocols that are part of the libp2p specs.

AgeManning commented 5 years ago

Yeah i see your point. I guess in my mind the interoperability part is accross implementations but not accross applications/networks.

I think giving the option to users to segregate their network from other applications is strictly better than not doing so, as they can always use the defaults to interop with other nodes.

Curious about @raulk thoughts, as he initially suggested this.

raulk commented 5 years ago

I believe it’s a legitimate use case to use libp2p as the networking library of an independent network. Some applications may require stronger guarantees that are not enforceable in hybrid networks. We don’t support overlay network (logical segregation) on top of a single physical network yet, so segregating in the manner suggested here should create a similar effect. On a different note, I think it’s fine to standardise the behaviour of libp2p protocols without obliging users to run them on a singleton swarm/network.

tomaka commented 5 years ago

In practice, only Kademlia requires customization, right? Ping and identify across networks doesn't hurt in any way as far as I can tell. Floodsub/gossipsub have topics whose names are network-specific. Only Kademlia could be harmful in the sense that it would discover nodes that are irrelevant.

raulk commented 5 years ago

Yeah, Kademlia would require customisation on the grounds that it stores state, and you might not want to leak state across networks. But IMO the ultimate segregation comes by customising the Multistream protocol ID. The go implementation allows this and several downstreams like OB1 use it.

AgeManning commented 5 years ago

If go allows this segregation, perhaps we add this into gossip and floodsub as well.

We are in discussion about the protocol id for floodsub/gossipsub for eth2 nodes. Currently this is leaning towards a custom Id. It would be nice to not be restricted based on the rust implementation.

I agree this shouldn't be an issue if topics are distinct, but would be nicer to segregate the name space, so eth2 and substrate for example could both have a 'block' topic (for lack of a better example) without overlap.

AgeManning commented 5 years ago

Kademlia has been updated.