You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on paritytech/polkadot-sdk#1631 I tried upgrading litep2p to use multiaddr-0.18.1 also used by libp2p-0.52.3. The thing with multiaddr-0.18.1 is that it uses libp2p_identity::PeerId as a payload of Protocol::P2p instead of Multihash in the older versions.
So, we have three options:
Make litep2p indirectly depend on libp2p-identity via multiaddr, but keep distinct PeerId types. We would need to add conversion between libp2p & litep2pPeerId types to litep2p.
Completely replace all PeerId types used in litep2p & polkadot-sdk by libp2p_identity::PeerId.
Introduce own Multiaddr implementation into litep2p with a layer of abstraction in polkadot-sdk like it's currently done with PeerId types.
I don't think route 3 is a good idea due to code duplication and layers of abstraction more heavy than the ones for PeerId, and a lot of code touched overall.
To proceed with paritytech/polkadot-sdk#1631 I'm going to go route 1 for now, but we should at least consider route 2 as something that would simplify things.
I'm no longer a maintainer of litep2p/sc-network and don't have a strong opinion on this but if I was, I wouldn't go for 1) or 2). I don't think the issue is litep2p but in Polkadot SDK because, IIUC, it's using two libraries that provide incompatible versions for some type (Multiaddr). 3) would temporarily add some extra code to Polkadot SDK (litep2p could just re-export its multiaddr) because sc-network-types would have to implement some wrapper code for libp2p and litep2p but that wrapper code could be kept very thin and only implement the parts that Polkadot SDK uses. Eventually one of the libraries will get removed from Polkadot SDK and all the wrapper code will be removed along with it. Having temporary wrapper code to work under special circumstances (two libp2p implementations) is IMO a better way to deal with the issue than introducing a new dependency that is not in the control of Parity. The reason litep2p was written was because libp2p kept breaking stuff in every release and in typical fashion stuff broke again, this time in one of its dependencies.
All that said, I think you should do whatever works best for Parity, that's why litep2p exists in the first place :)
While working on paritytech/polkadot-sdk#1631 I tried upgrading litep2p to use
multiaddr-0.18.1
also used bylibp2p-0.52.3
. The thing withmultiaddr-0.18.1
is that it useslibp2p_identity::PeerId
as a payload ofProtocol::P2p
instead ofMultihash
in the older versions.So, we have three options:
litep2p
indirectly depend onlibp2p-identity
viamultiaddr
, but keep distinctPeerId
types. We would need to add conversion betweenlibp2p
&litep2p
PeerId
types tolitep2p
.PeerId
types used inlitep2p
&polkadot-sdk
bylibp2p_identity::PeerId
.Multiaddr
implementation intolitep2p
with a layer of abstraction inpolkadot-sdk
like it's currently done withPeerId
types.I don't think route 3 is a good idea due to code duplication and layers of abstraction more heavy than the ones for
PeerId
, and a lot of code touched overall.To proceed with paritytech/polkadot-sdk#1631 I'm going to go route 1 for now, but we should at least consider route 2 as something that would simplify things.
CC @altonen @lexnv
The text was updated successfully, but these errors were encountered: