Replace Multiaddr & related types with substrate-specific types
#4198
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dmitry-markin
changed the title
Multiaddr & Multihash typeslibp2p-identity types with substrate-specific types
dmitry-markin
added a commit
to paritytech/litep2p
that referenced
this pull request
Apr 23, 2024
|
The CI pipeline was cancelled due to failure one of the required jobs. |
dmitry-markin
changed the title
libp2p-identity types with substrate-specific typeslibp2p-identity related types with substrate-specific types
dmitry-markin
changed the title
libp2p-identity related types with substrate-specific typesMultiaddr & related types with substrate-specific types
bkchr
approved these changes
May 18, 2024
Member
bkchr
left a comment
bkchr
left a comment
There was a problem hiding this comment.
Didn't look that closely, but these are mainly wrappers any way?
|
|
||
| /// Convert public key to `PeerId`. | ||
| pub fn to_peer_id(&self) -> PeerId { | ||
| litep2p::PeerId::from(litep2p::crypto::PublicKey::Ed25519(self.clone().into())).into() |
Member
There was a problem hiding this comment.
Can we not directly construct the PeerId?
Contributor
Author
There was a problem hiding this comment.
This would require hashing PublicKey type serialized as protobuf, and I tried to avoid including the protobuf schema into the already bloated wrapper sources.
lexnv
reviewed
May 20, 2024
| } | ||
| } | ||
|
|
||
| // TODO: uncomment this after upgrading `multihash` crate to v0.19.1. |
Contributor
There was a problem hiding this comment.
Is there anything blocking us from updating to multihash 0.19.1? Maybe we could do that in a followup and raise an issue to not forget about it?
Contributor
Author
There was a problem hiding this comment.
Yes, it should be done at the same time as upgrading libp2p. I will mention it in the libp2p PR.
lexnv
reviewed
May 20, 2024
Contributor
lexnv
left a comment
lexnv
left a comment
There was a problem hiding this comment.
LGTM! Nice job here!
There are a few CI steps that are failing, but other than that we are good to go 👍
lexnv
approved these changes
May 21, 2024
hitchhooker
pushed a commit
to ibp-network/polkadot-sdk
that referenced
this pull request
Jun 5, 2024
…ritytech#4198) This PR introduces custom types / substrate wrappers for `Multiaddr`, `multiaddr::Protocol`, `Multihash`, `ed25519::*` and supplementary types like errors and iterators. This is needed to unblock `libp2p` upgrade PR paritytech#1631 after paritytech#2944 was merged. `libp2p` and `litep2p` currently depend on different versions of `multiaddr` crate, and introduction of this "common ground" types is needed to support independent version upgrades of `multiaddr` and dependent crates in `libp2p` & `litep2p`. While being just convenient to not tie versions of `libp2p` & `litep2p` dependencies together, it's currently not even possible to keep `libp2p` & `litep2p` dependencies updated to the same versions as `multiaddr` in `libp2p` depends on `libp2p-identity` that we can't include as a dependency of `litep2p`, which has it's own `PeerId` type. In the future, to keep things updated on `litep2p` side, we will likely need to fork `multiaddr` and make it use `litep2p` `PeerId` as a payload of `/p2p/...` protocol. With these changes, common code in substrate uses these custom types, and `litep2p` & `libp2p` backends use corresponding libraries types.
nazar-pc
reviewed
Jun 21, 2024
| /// or litep2p's `Multiaddr` when passed to the corresponding network backend. | ||
|
|
||
| #[derive(PartialEq, Eq, PartialOrd, Ord, Clone, Hash)] | ||
| pub struct Multiaddr { |
Contributor
There was a problem hiding this comment.
This version is missing impl From<IpAddr> for Multiaddr from libp2p's implementation, can you add it?
1 task
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 21, 2024
Add `From` implementation used by downstream project. Ref. #4198 (comment) CC @nazar-pc
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this pull request
Aug 2, 2024
…ritytech#4198) This PR introduces custom types / substrate wrappers for `Multiaddr`, `multiaddr::Protocol`, `Multihash`, `ed25519::*` and supplementary types like errors and iterators. This is needed to unblock `libp2p` upgrade PR paritytech#1631 after paritytech#2944 was merged. `libp2p` and `litep2p` currently depend on different versions of `multiaddr` crate, and introduction of this "common ground" types is needed to support independent version upgrades of `multiaddr` and dependent crates in `libp2p` & `litep2p`. While being just convenient to not tie versions of `libp2p` & `litep2p` dependencies together, it's currently not even possible to keep `libp2p` & `litep2p` dependencies updated to the same versions as `multiaddr` in `libp2p` depends on `libp2p-identity` that we can't include as a dependency of `litep2p`, which has it's own `PeerId` type. In the future, to keep things updated on `litep2p` side, we will likely need to fork `multiaddr` and make it use `litep2p` `PeerId` as a payload of `/p2p/...` protocol. With these changes, common code in substrate uses these custom types, and `litep2p` & `libp2p` backends use corresponding libraries types.
TarekkMA
pushed a commit
to moonbeam-foundation/polkadot-sdk
that referenced
this pull request
Aug 2, 2024
…4855) Add `From` implementation used by downstream project. Ref. paritytech#4198 (comment) CC @nazar-pc
This was referenced Aug 21, 2024
This was referenced Oct 4, 2024
sfffaaa
pushed a commit
to peaqnetwork/polkadot-sdk
that referenced
this pull request
Dec 27, 2024
…4855) Add `From` implementation used by downstream project. Ref. paritytech#4198 (comment) CC @nazar-pc
gztensr
added a commit
to gztensr/litep2p
that referenced
this pull request
Dec 24, 2025
This is a companion PR to paritytech/polkadot-sdk#4198.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces custom types / substrate wrappers for
Multiaddr,multiaddr::Protocol,Multihash,ed25519::*and supplementary types like errors and iterators.This is needed to unblock
libp2pupgrade PR #1631 after #2944 was merged.libp2pandlitep2pcurrently depend on different versions ofmultiaddrcrate, and introduction of this "common ground" types is needed to support independent version upgrades ofmultiaddrand dependent crates inlibp2p&litep2p.While being just convenient to not tie versions of
libp2p&litep2pdependencies together, it's currently not even possible to keeplibp2p&litep2pdependencies updated to the same versions asmultiaddrinlibp2pdepends onlibp2p-identitythat we can't include as a dependency oflitep2p, which has it's ownPeerIdtype. In the future, to keep things updated onlitep2pside, we will likely need to forkmultiaddrand make it uselitep2pPeerIdas a payload of/p2p/...protocol.With these changes, common code in substrate uses these custom types, and
litep2p&libp2pbackends use corresponding libraries types.