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

Somehow combine go-libp2p-crypto and go-libp2p-peer #484

Closed
Stebalien opened this issue Nov 14, 2018 · 6 comments
Closed

Somehow combine go-libp2p-crypto and go-libp2p-peer #484

Stebalien opened this issue Nov 14, 2018 · 6 comments

Comments

@Stebalien
Copy link
Member

Peer IDs and keys are closely tied together. Unfortunately, they currently live in two separate packages. My current thinking is either:

  1. Move crypto into peer (and make a new crypto that depends on peer and re-exports).
  2. Combine into go-libp2p-identity and create a new peer and crypto facade.

My motivation is fixing libp2p/specs#111. We need to be bale to deterministically derive peer IDs from keys. That means keys nee to remember their multihash. However, that's a peer-ID concern which doesn't really fit in the current go-libp2p-crypto package.

@raulk this is related to your monorepo suggestion and, IMO, a good start. We could also combine these packages with a few others if we have some other "core" concepts.

Note: fixing libp2p/specs#111 is a rather high priority so I don't want to block it on reworking all of our dependencies.

@Stebalien
Copy link
Member Author

(and libp2p/specs#111 can be fixed, for now, by just getting rid of peer-id inlining and re-introducing it when we add the correct field to the key protobuf).

@vyzo
Copy link
Contributor

vyzo commented Nov 15, 2018

I am in favour of having a meta-package for this; crypto is useful outside the concept of peer.

@raulk
Copy link
Member

raulk commented Nov 15, 2018

@Stebalien agree it'd be good start to consolidating repos. I don't suppose we'd entertain the idea of moving both peer and crypto to somewhere more central, though?

go-libp2p wouldn't be that place, because clients can instantiate libp2p without importing go-libp2p (ironically), i.e. if they're using BlankHost.

In our current layout, that central place could be go-libp2p-host. You really cannot have libp2p without importing Host; so it's an unconditional dependency.

go-libp2p-host
  |___ id
  |___ crypto
  |___ ...

If somebody really wants to use PeerID outside of libp2p (?), or use our crypto constructs, they can still do so by importing these packages directly.

@Stebalien
Copy link
Member Author

I'm going to take a stab at making a go-libp2p-interfaces package.

@emad-elsaid
Copy link

Is there any changes to the implementation or a decision made about this issue?

@Stebalien
Copy link
Member Author

All core interface libraries have been merged into go-libp2p-core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants