Is libp2p suitable to build a node for a existing non-libp2p network?

Users and Developers
1

I’m currently investigating using libp2p to build a node for an existing p2p network that is not built using libp2p and have some questions/requesting advice. I’m very new to p2p tech in general so some of my questions may be a bit ignorant - feel free to make any corrections/etc.

I plan to use the Rust implementation if I go with libp2p (but would also be open to the JS impl if there was a need/limitation with Rust).

Very brief overview:

  • Network is over TCP
  • Doesn’t use encryption (currently)

Questions:

  1. Is it possible to use a custom handshake/protocol negotition? The network requires a specific handshake before any other p2p messages are sent, it looks something like: Connect to remote over TCP → SendPeerHandshake message → ReceivePeerHandshakeResponse message → now we can handle other messages.

  2. Is it possible to run libp2p without any encryption (Rust impl)?

  3. The way it gathers peers is by bootstraping from a known set of peers and then sending “ListPeers” messages to known peers and receiving “KnownPeers” messages, is it possible to use “custom peer gathering” like this?

  4. How/would mplex (or whatever it is) work with other nodes that aren’t libp2p based?

  5. Does it make sense to use libp2p on a network where other nodes aren’t using libp2p? My gut feeling is libp2p provides a lot of useful core functionality whereby it is still worth using if I can accomplish the above

  6. Any general advice/suggestions/recommendations would be very much appreciated

Thank you.

2

Libp2p’s is mainly made for you to be able to add more features not remove some.
You can implement your own transport that implements an exchange sequence that the other nodes are using.
You can implement your own encryption layer that doesn’t encrypt anything.
You can implement your own muxer that does not mux.
However the scary word you said is message, currently libp2p is not message oriented it is stream oriented. Adding more message oriented support was thought about in the past but I don’t know where it is at now.

If you write your own transport yes.

Basically if you make your own transport you have some interface you have to fit in (listen, dial, …) and you will then be tasked to implement networking (could be as easy as just opening a TCP stream), security and multiplexing.
You don’t have to use (tcp and (yamux or mplex) and (tls or noise)) or quic, you can use whatever you want and that relatively easy to do.

In go as well as in rust you can also choose to implement part of it,
For example you could implement your own networking and security layer but reuse the multiplexing one.

The rust implementation is slightly different than the go one I’m describing (because it pipelines slightly more transports, basically security and muxing are seen as transports that upgrade an already existing connection).

The Libp2p Core does not have peer discovery builtin, this is provided by pubsub, kadamelia, , … services that runs on top.

So your peer exchange service running on top would be just like we do peer discovery already.

It’s mainly yamux or QUIC’s builtin multiplexer theses days.
But this wouldn’t play very nice, you might be able to hack something together.

I don’t think so, the positives of libp2p are

  • it provide P2P networking with encrypted and multiplexed connections
  • it has some high level concepts more or less all implementations understand (peer ids, encryption, multiplexed streams, …) so you can take a rust libp2p node and make it talk with a go-libp2p one.
  • some protocols you might want to use are built on top of it (bitswap, kadamelia, eth2 consensus, …)
  • it is extremely extensible (you can add your own transports, multiplexers, security and services)

No one of it you are taking advantage of. From what I understand the only thing you would keep is the glue code, maybe I am missing something but it seems to me that the glue is the part that is easy (altho a bit boring) to write.

1 Like
3

Thank you very much for the detail response - extremely helpful.

I might spike something out with libp2p for fun and see how it goes, otherwise it seems like it might not be a good fit for my use-case.

Thanks again.

1 Like