Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
⚗️Libp2p to replace network layer? #739
referenced this issue
Feb 3, 2019
State of rust-libp2p
The following list is obviously not exhaustive and only contains stuff which is interesting for us.
What is supported
What is not supported
Other interesting stuff
What we can replace
Basically our whole networking stack, that is
What we would have to do
Things to think about down the line
If we would use libp2p as the network layer, we could get around to only requiring the other node's ID (COMIT nodes are very likely to have a stable ID as we would generate it once and re-use it.) in the HTTP endpoint because we can utilize
How do multi-addresses fit into the picture?
What I suggest that we should do:
Go ahead and
referenced this issue
Feb 10, 2019
Yes. I thought that is implied by the fact that it is not there :)
They also depend on snow, so it is using the same noise implementation under the hood. Regarding the handshake, they took a different approach which I don't quite understand yet but that may be because I haven't fully understood the architecture of
Will add information in regards to that.
Sounds reasonable to me but also quite time intensive.
Meaning, this will lead us back to a situation where we should do a propper evaluation.
What are the problems we are facing?
I partly addresses this in
In addition, the 2nd paragraph of "Things to think about down the line" mentions something interesting in regards to handling connections altogether:
As an alternative, we have to pass actual connection information (an IPv4 f.e.) which limits is in the way we can connect to other peers. (f.e. NAT)
Have we solved them already only partly and they do it better?
Yes. I would say they solve it better because building a network stack is the sole purpose of
What consequences will this have in regards of our RFCs and the rest of the code base?
Regarding the RFCs. Those are only concerned with the message design and the communication that happens once a connection is established. They don't say anything about how connections are established. However IF we were to adopt
This is what we would have to specify in above mentioned RFC.
Are any other solutions out there?
Not that I am aware of. However, answering such question is a bit out of scope of the spike. The goal is to evaluate whether
I think we can close this spike as it is done. Evaluation is done, thank you and well done @thomaseizinger !
The aim was to understand what libp2p can bring to comit-rs. Now that we know what we could use, I see 2 non-exclusive ways to move forward:
My proposal: we do 1. and as part of each created issue do a pre-work: "check if there are worthy alternative solutions to this problematic".
@comit-network/rust-devs any objections? Please use your emojis