Implement a libp2p network backend

[tomaka]

Now that network and network-devp2p are separate, we can add an alternative backend for libp2p.

This is important if we want to put a light client in the browser, as devp2p requires dialing an UDP port, which isn't possible in the browser.

[tomaka]

One open problem is how to handle command line arguments in order to possibly ensure a smooth transition to both the devp2p and libp2p backends simultaneously, or from devp2p to libp2p in case Ethereum as a whole changes its protocol.

Right now all the networking-related options of Parity look like --port, --bootnodes, and so on.
If I create --libp2p-port, --libp2p-bootnodes, etc. then would we renamed --port to --devp2p-port eventually? I'm not sure how to handle a transition.

[tomaka]

When it comes to the CLI, here is what I'm going with:

• The --with-libp2p flag enables libp2p.
• --no-devp2p allows disabling devp2p.
• --libp2p-port specifies the port that libp2p uses.
• --libp2p-bootstrap specifies a list of bootstrap nodes for libp2p.
• The --reserved-peers flag will try to parse each node address as either devp2p or libp2p, and dispatch as appropriate.
• --min-peers and --max-peers apply to both devp2p and libp2p.
• --port and --bootstrap specify the port and bootstrap nodes for devp2p.

Using --libp2p-port or --libp2p-bootstrap or specifying a libp2p reserved node while libp2p is disabled will produce a warning, and same for the devp2p equivalents.

I think that this scheme is what makes the most sense, but don't hesitate to comment on this.

[dvdplm]

How about adding a --network-backend switch that can be set to devp2p or libp2p and leave --port/--bootnodes as they are? Or can users run both networking backends at the same time?

[tomaka]

Or can users run both networking backends at the same time?

Yes. Full nodes need to run both in order to make the bridge.

[richard-ramos]

@tomaka,

In regards to the idea of putting a libp2p light client in the browser, is this light client going to be implemented as a javascript package? or will a browser extension be built for such purposes?
If it's the first option, I'm wondering if this client will communicate with the bridge nodes using webrtc? if this is the case, do you have plans to build a signaling service in the nodes?

I'm asking with because I'm currently working in a Whisper v6 javascript node that can be used in the browser with libp2p: https://github.com/status-im/murmur that requires a devp2p <-> libp2p bridge in order to communicate with standard whisper nodes, and to do this communication, it depends on a centralized signal server to perform the handshake, (since websocket servers cannot be started in the browser),

So... I was wondering if you have figured out how to solve this problem? (I'm still researching the best way to avoid having a single point of failure represented by this signaling server)

[tomaka]

Progress has almost completely stalled, however my idea was to embed directly the node in Js/Wasm, and that full nodes would support both libp2p and devp2p and would act as a bridge.

After all, you can't run a full node in a browser anyway, you would only run a light client. Even on native, light clients need full nodes to function, so why node extend these functionalities to bridging libp2p and devp2p.

I must admit that I'm not so familiar with Whisper, but Ethereum doesn't require direct connections between nodes. In other words, as long as you're connected to one node of the network, you are connected to the network. Two nodes behind a NAT and inside a browser never really have to talk to each other directly.

[richard-ramos]

Thanks for the prompt reply!

I see... in this case the design of my whisper node differs from this light client, because I want to have a libp2p network working independently of devp2p, with browser nodes being able to discover peers, broadcast and receive messages between each other, with devp2p bridges just being another participant in this libp2p network.

Well, looking fwd to see in the future how this libp2p backend for parity is implemented when progress resumes! Cheers!

[adria0]

Closing issue due to its stale state.