I am wondering. We already have a peerid which is derived from the provider's address. If I am not mistaken. That peerid is later used in deals etc. How is the p2p peer id used? I imagine those two peerid should be the same?

Sooo. I was thinking about the retrieval. Currently the p2p network and polkadot parachain store different peer ids for the same provider. That means that our custom p2p network only knows how to map the p2p peer id to the multiaddress. The idea for "retrieval name resolver" was that we fetch the peer id for a specific deal from the chain. But that currently wouldn't work because the one stored on the chain is different from the one used by the custom p2p network.

Please correct me if I am wrong.

I am wondering. We already have a peerid which is derived from the provider's address. If I am not mistaken. That peerid is later used in deals etc. How is the p2p peer id used? I imagine those two peerid should be the same?

Sooo. I was thinking about the retrieval. Currently the p2p network and polkadot parachain store different peer ids for the same provider. That means that our custom p2p network only knows how to map the p2p peer id to the multiaddress. The idea for "retrieval name resolver" was that we fetch the peer id for a specific deal from the chain. But that currently wouldn't work because the one stored on the chain is different from the one used by the custom p2p network.

Please correct me if I am wrong.

@cernicc The Peer ID on chain and the Peer ID in the P2P network are both derived from the same ED25519 private key. When the storage provider first registers on-chain they create an ED25519 private key, derive the Peer ID using the polka-storage-client and register themselves on-chain with this Peer ID. Basically the Peer ID on-chain is something that is generated externally and is the same that the storage provider uses to register within the P2P network

looks great. Should we update the documentation for p2p_key to specify that it is used both for on–chain registration and for the custom P2P network? This may reduce any confusion about why two different peer IDs aren’t generated

Also I like the approach of making the p2p arguments optional except when running as an authority. Perhaps we could have clap enforce these conditionally (if possible) to give users immediate feedback rather than only at runtime?