IPFS ignores PeerID passed by libp2p instance - too many ways of passing peer-id

[EmiM]

• Version:
  "ipfs": "0.52"

• Platform:

• Linux rf-Lenovo-ideapad-320-15IKB 5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

• nodejs

• Subsystem:
  libp2p

Severity:

Low/Medium

Description:

IPFS ignores PeerID passed by libp2p instance.
This is the draft of my code:

peerID = PeerId.create()  // let's assume that this peerID is static, e.g read from file
libp2p = Libp2p.create({peerId: peerID, (...)})
ipfs = await IPFS.create({
      libp2p: () => libp2p,
      preload: { enabled: false },
      repo: targetPath,
      EXPERIMENTAL: {
        ipnsPubsub: true
      },
    })

The result of running the code above: Identity.PeerID saved in config file created by IPFS differs from peerID passed to libp2p. It causes further syncing problems with library that uses ipfs - orbitdb.

What I expect: IPFS uses peerID that I passed to libp2p.
What happened: IPFS completely ignores the peerID I passed and creates its own peerID. It uses privateKey from options or private key from Repo.

I managed to fix the problem by passing privateKey: peerID.toJSON().privKey to IPFS.create.

It's very confusing, especially that there are multiple ways of passing peer-id to IPFS and one of them that I would expect to work, doesn't work.
I've created a topic on your forum: https://discuss.ipfs.io/t/ipfs-ignores-peerid-passed-to-custom-libp2p-instance/10452, @vasco-santos suggested that IPFS could:

• throw an error if multiple peer-id are provided
  or
• add more docs on such configuration

Besides that, I think that IPFS should not ignore PeerID from libp2p.

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[momack2]

Thank you for the report!

• @johnnymatthews / @yusefnapora - could one of you add some docs on this to https://docs.libp2p.io/concepts/peer-id/?
• https://github.com/libp2p/js-peer-id seems to be the other place we have docs - maybe that's the right place to link such docs for "how to import a peer-id"? Looks like @vasco-santos is the lead maintainer there!

[vasco-santos]

@momack2 the configuration issue here is a conflict between a user configuring libp2p via js-ipfs + what js-ipfs does to configure libp2p itself:

• js-libp2p creates factory receives a PeerId, as part of a configuration object, to create a libp2p node
• js-ipfs allows a user to bring their own libp2p configuration
• js-ipfs/go-ipfs repo includes nodes configuration, including its cryptographic primitives (peerId, privateKey, publicKey, ...)

So what happens in this case is that IPFS repo already has a PeerId defined, but IPFS allows libp2p to be configured with another PeerId, which will be overwritten by IPFS when setting the repo's PeerId.

With the above considerations, this is a js-ipfs issue and what we need to decide is:

• what should happen when "competing" peerIds exist
• properly document the expectations in js-ipfs

As a side note, there is a lot of room for configuration improvements on js-ipfs and js-libp2p. This has been one of the pain points of users

EDIT: We are only talking about the peerId here, but I suspect this problem might exist on other configuration properties like the swarm addresses configured in IPFS config file, which are forwarded to the libp2p config (and probably overwrite user provided configs within libp2p scope)

[BigLep]

@vasco-santos: who owns the next steps here?

[vasco-santos]

This needs an analysis of the scope of this issue first, as this is not only a peer-id, but all the configuration that overlaps with libp2p like addresses. With all the information we need to discuss the solution. @achingbrain should give input on the solution.

This can be included in protocol/web3-dev-team#82 or as a maintenance task (probably for the onboarding team?)

[momack2]

Seems like a simple v0 is just to define what does and doesn't work in the docs, and the work around that EmiM suggested (aka if you're using IPFS, your libp2p configurations will be overwritten and need to be passed directly to the IPFS constructor). Seems like something that @johnnymatthews @johndmulhausen can document!