Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate network layer to libp2p #800

Closed
thomaseizinger opened this issue Feb 28, 2019 · 4 comments

Comments

Projects
None yet
5 participants
@thomaseizinger
Copy link
Member

commented Feb 28, 2019

Based on the outcome of #779, the network layer of COMIT should be replaced with libp2p.

Since libp2p is a modular network stack, I'd propose the following configuration to begin with:

  • Only TCP transport
  • Discovery through WebRTC-star (or should be go with mDNS for now since we are always on the same network?)
  • no encryption

This should allow us to run our tests again.

The following things will need to be done (not necessarily in this order):

  • Throw away comit_server and connection_pool
  • Figure out away on how to put BAM ontop of whichever abstractions libp2p exposes. This will involve registering a protocol with libp2p like /bam/1.0.0.
  • Change the http_api to accept a libp2p node id instead of an IP address
  • Figure out how to establish a connection to the given ID so that the swap request can be sent to the other guy. Not sure if libp2p will handle the discovery transparently for us or we have to do this manually before sending the request
  • Derive the keypair used for the libp2p id from the seed specified in the configuration file
  • Put COMIT on the list of notable users: https://github.com/libp2p/rust-libp2p#notable-users

Note:

  • aim for multiple PRs
  • create issues per PR
  • Pair programming
@thomaseizinger

This comment has been minimized.

Copy link
Member Author

commented Apr 1, 2019

rust-libp2p switched to libsecp256k1 from secp256k1 which is a pure Rust implementation in order to support WASM as a compile target better.

However, that one hasn't received nearly as many security audits (if any) as secp256k1 has. Not sure if this a concern to us.

@LLFourn

This comment has been minimized.

Copy link
Contributor

commented May 1, 2019

@thomaseizinger are we using libsecp256k1 for anything?

@thomaseizinger

This comment has been minimized.

Copy link
Member Author

commented May 2, 2019

@thomaseizinger are we using libsecp256k1 for anything?

We are now, implicitly by depending on libp2p.

@thomaseizinger

This comment has been minimized.

Copy link
Member Author

commented May 2, 2019

This has been resolved by merging #878.

@bonomat bonomat removed the review label May 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.