feat: introduce libp2p-identity crate

[thomaseizinger]

Description

This patch combines the libp2p_core::identity and libp2p_core::peer_id modules into a new crate: libp2p-identity.

Resolves #3349.

Notes

This initial patch only moves the code and adds feature flags. What is yet undecided is how we want to adjust the public API as part of this. The goal would be that the first release (0.1) is backwards compatible with what we currently ship. In a 2nd release, we then harden the public API such that breaking changes will be very unlikely in the future. As part of 0.2, I also want to remove the dependency on multiaddr to enable multiformats/rust-multiaddr#73 which requires multiaddr to depend on libp2p-identity.

What do people think about this plan? @mxinden @jxs @elenaf9

Links to any relevant issues

Open Questions

Further tasks

• Seal public API by making Keypair and PublicKey opaque structs. I think we should not have conditional enum variants. Those are a hazard. Someone could be exhaustively matching on them with one feature combination and adding a dependency that activates another suddenly causes the program to fail to compile. Even worse, this can happen in dependencies that don't add the necessary cfgs.

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[jxs]

Makes sense to me Thomas 👍

[mergify]

This pull request has merge conflicts. Could you please resolve them @thomaseizinger? 🙏

[thomaseizinger]

Change looks good to me minus the deprecation warning.

I've removed the deprecation warning.

Until we release these changes, we will have a broken CI because of #3350 (comment). Can you exercise your admin rights to merge this and make patch releases of all crates?

This PR attracts a lot of merge conflicts so I'd rather not keep it updated for a long time.

Friendly ping @mxinden.

[mergify]

This pull request has merge conflicts. Could you please resolve them @thomaseizinger? 🙏

[mxinden]

Update here. I won't get to releasing this today, thus not yet merging. Otherwise other pull requests are red in the meantime.

I hope to get to this Saturday or Monday.

@thomaseizinger no need to resolve merge conflicts in the meantime. Sorry for the delay.

[mxinden]

As discussed, semver check failure for libp2p-core is a false positive. Thus merging here. Will start the release process next.

[thomaseizinger]

Thank you for releasing this!

As part of the next breaking change, I want to remove the multiaddr dependency and clean up the API of libp2p-identity.

[drHuangMHT]

This kind of breaks my own implementation lol. I tried to keep PeerId and Keypair in the same place to unify the use. But opaque Keypair seems to make it harder to export keys? Because you cannot know the algorithm used in the keypair at a glance and I have to try calling those methods to see what it is, which is not so ergonomic. If you don't know that the algorithm is, it will be harder to import keys.

[thomaseizinger]

This kind of breaks my own implementation lol. I tried to keep PeerId and Keypair in the same place to unify the use. But opaque Keypair seems to make it harder to export keys? Because you cannot know the algorithm used in the keypair at a glance and I have to try calling those methods to see what it is, which is not so ergonomic. If you don't know that the algorithm is, it will be harder to import keys.

I am happy to add features to make exporting easier to use. I am not sure why our to_protobuf_encoding is actually unsupported for anything other than ed25519 (cc @mxinden ).

Getting the conditional compilation code right is extremely tricky with the current situation and I don't want to put that burden on any of our users hence the deprecation of the direct access to the enum. If you get that wrong and your code happens to be another library, you can easily produce unresolvable compile-errors for the users of your library.

We could add a KeypairKind enum that allows you to branch accordingly. Would that be an acceptable solution?

[thomaseizinger]

The specs don't mention anything about key types being deprecated so I think we could add support for encoding the older key types via protobuf.

@mxinden may have more context here on why we don't currently support them.

What is your usecase for using non-ed25519 keys? Those should certainly be the preferred ones.

[drHuangMHT]

What is your usecase for using non-ed25519 keys? Those should certainly be the preferred ones.

That actually doesn't matter. I'll open a discussion and see what I can do there.

[mxinden]

The specs don't mention anything about key types being deprecated so I think we could add support for encoding the older key types via protobuf.

@mxinden may have more context here on why we don't currently support them.

I introduced the protobuf functionality in #2090 in order to import IPFS configs in https://github.com/mxinden/rust-libp2p-server/. I only implemented ed25519 because I didn't need any other. I am not aware of any other reason why the others are not implemented. In other words, contributions welcome.

[thomaseizinger]

I opened an issue here: #3630