We use ipfs-js version 0.52.3 because that is the latest version supported by OrbitDB.
The issue I experienced appeared on the OrbitDB side - databases suppose to sync immediately when peer connects to the network but it was not happening.
After digging through the IFPS code I noticed that it ignores PeerId passed to libp2p instance (that we pass to IPFS.create) and creates new peerId. As a result the OrbitDB was hanging because it was trying to connect with .
IPFS creates new PeerId if you do not pass privateKey (PeerID.privKey) in options (method Storage.initRepo) so I passed a key of the peerid we use in our libp2p instance and it fixed the issue.
This is the draft of a setup we have in our project:
peerID = PeerId.create()
libp2p = Libp2p.create({peerId: peerID, (...)})
ipfs = await IPFS.create({
libp2p: () => libp2p,
preload: { enabled: false },
repo: targetPath,
EXPERIMENTAL: {
ipnsPubsub: true
},
privateKey: peerID.toJSON().privKey // This is added as a fix
})
My questions are if that is the expected behavior and is this an only option to make IPFS work with custom libp2p and pregenerated PeerID?
Hey @EmiM
This seems to be related to the usage of an already created repo? The repo will have a peer-id and it will probably default to use that.
My doubt here is what would be the expectations since 2 different peerIds might be provided
I was removing whole directory under targetPath before some tests so I think I would notice if it was the case. Or are you talking about something else?
I also can’t see a place in IPFS code where passed PeerId would be used, only privateKey. Maybe I am missing something?
I mean, that if a repo exists in the targetPath it will likely take priority to what you configure for a peer-id.
Looking at the code, IPFS has no visibility that you are configuring a peerId in libp2p. This way, either it uses the one from the repo, or it will create a new one, or you provide the private key. After the IPFS initialisation, it will provide that peerId to the config, so it will likely override the one you provided.
This is a problem of having multiple ways of configuring things. It is probably worth to create an issue in js-ipfs to either throw an error if multiple peer-id are provided, or just more information on the expectations of such a configuration in the docs. Would you like to open the issue?
Sure, I’ll open the issue, thank you for the response. Yeah, the multiple ways of configuring ipfs and ignoring peerId from libp2p is a bit confusing.