Re-export multihash from libp2p-identity with peerid feature

[dav1do]

Summary

Bug might be a stretch given how integral multihash is to all libp2p things, but I think libp2p-identity should re-export multihash as it uses it in a public api and it's a crate that could stand on its own.

I noticed this while writing a similar issue in rust-multiaddrs. It's not impacting me currently, but I got started thinking about the dependencies between all these crates and noticed it.

Expected behavior

You can use libp2p-identity without a dependency on multihash.

Actual behavior

could not find multihash in libp2p_identity

Relevant log output

// for example, this would compile without an explicit multihash dependency

// [dependencies]
// libp2p-identity = { version = "0.2", features = ["peerid"] }

use libp2p_identity::{PeerId, multihash};

fn main() {
    let hash = multihash::Multihash::<64>::default();
    let peer_id = PeerId::from_multihash(hash).unwrap();
}

Possible Solution

pub use multihash to re-export multihash in peer_id.rs

Version

libp2p-identity = { version = "0.2.8", features = ["peerid"] }

Would you like to work on fixing this bug ?

Yes

[thomaseizinger]

Thanks for the report!

I don't think it is super important. We started to be very conservative with minor version bumps in rust-multihash so adding a separate dependency shouldn't cause much friction.

I'd hope that we can release 1.0 of rust-multihash with an API similar to the current one at which point we no longer need to re-export it. Removing the re-export is a breaking change of libp2p-identity which I'd also like to avoid because it is a fundamental dependency of the libp2p ecosystem.

[dav1do]

Hey! Thanks for the reply. That's fair, closing with some rambling :).

Before I wrote this, I noticed that libp2p-core re-exports multihash, and I was thinking if it got its version from libp2p-identity, it would help consumers of this standalone crate like multiaddr, and keep a consistent version in the libp2p workspace.

I didn't really mention that in the issue because I started writing a discussion post about the multiformats dependencies and the best way to expose them, planning to link back, and then I decided it works now and it's not that important.. and here I am bringing some of it up anyway.

I think the multiformats dependencies are particularly interesting because they're so integral to the libp2p ecosystem and used in lots of public interfaces (not just in rust, and not just in libp2p). They're a bit like serde in their ubiquitousness in projects in the interplanetary ecosystem. Right now, having IPLD, multiformats, libp2p crates on different versions of multiformats crates is rough, especially if their version is private. Since a multiformats version bump causes so many waves, I was pondering if it could be controlled from a single place and be sourced upwards (and wondering if this might be that place). Anyway, getting to a stable API will alleviate it, and it will be like serde where you can pick anything over 1.0 and it just works.

[thomaseizinger]

Anyway, getting to a stable API will alleviate it, and it will be like serde where you can pick anything over 1.0 and it just works.

Exactly! There have been some efforts already to move towards 1.0 (see multiformats/rust-multihash#267). I don't have capacity to drive this effort further so any help there would be much appreciated! :)