IPFS> IPNS Even if I publish different folders, I always get the same peerID

Help
#2

it’s how it’s supposed to work.
IPNS use the peerid as the key.
So you do /ipns/k51qzi5uqu5di...........nqjyf03xzdd659kovr8 to fetch the data.

#3

Ok, thanks for answering me. In fact, I did the same operations on another server and got different peerIDs for different folders.

But here, where is the problem? For the sake of completeness, I must say that in another server trying the same sequence of commands I got different peerIDs but, as soon as I tried using the ipfs add -w command, I was no longer able to get different peerIDs as before! I’ve been going crazy since last night. Where is the problem ???

#4

I hope someone can help me because after setting up 5 servers this is very disappointing.

#5

Are you running this command on different servers ?

#6

Yes, right now. On another server, I always get the same peerID for different folders

#7

Sounds like there’s a bit of a terminology problem. The peerId is the immutable part that’s published so if you publish different contents that’s the part that will remain the same. It doesn’t have to be the peerID but that’s just the default. The peerId should resolve to different CIDs as you publish a new record which is the mutable part.

There are lifetime and ttl values associated with the record so they may be cached which might be why you might not be seeing a new CID even though you’ve published a new record. There is a —nocache option on ‘IPFS name resolve’. It’s not totally clear of that’s “don’t use a cached value” or “don’t cache the value you resole”. I’d be interested in knowing which that is.

#8

Blockquote
The peerId is the immutable part that’s published so if you publish different contents that’s the part that will remain the same

But if I publish 2 different folders, should I get two different peerIDs or not?

#9

If you publish it using the same key ( the peerId in this case ) the peerId won’t change. The CID that the peerId resolves to will change.

It’s a bit like DNS where the peerId is the domain name and the CID is the IP address it resolves to. When you publish a new record the domain name ( peerId ) doesn’t change but the IP address ( CID ) changes.

I’m not sure if the problem is how you’re thinking about it or if you’re just referring to the wrong thing as the peerId.

#10

Forgive me for bad English.
What I understood from reading the documentation is that:

ipfs add -r folder1 >ipfs name publish CID_folder1 >ipfs name resolve peerID_folder1
ipfs add -r folder2 >ipfs name publish CID_folder2 >ipfs name resolve peerID_folder2

should peerID_folder2 be different from peerID_folder1 or not?

After that if for example I try to publish the folder again because the “content” of a file has changed, or because I added a file, this works.

#11

peerID_folder2 == peerID_folder2

You need to specify a key to use with --key if you want them to be different.

#12

A key? Can you explain it better?

#13

it’s just which private is used to sign the record, each private key has a different corresponding peer id.

#14

Thank you!
Thank you. How stupid, I didn’t understand. The problem was the key. Without a key you will always get the same peerID even with different sites!

ipfs key gen --type=rsa --size=2048 myfolder
ipfs add -r myfolder
ipfs name publish --key=datafolder CID_folder

Solved, thanks!

#15

Can someone clarify the use of the term PeerId ( I understand what it is)

Would you refer to secondary keys created as peerID’s even though they’re not being used to identify a node? The term is just a little confusing because the default peerid is being used for two different things

#16

I personally wouldn’t call the generated keys PeerIDs. Even though it is possible to swap out the default key in kubo. I would just call them keys

2 Likes
#17

I agree. I had some issues by running Kubo AND Brave Browser Beta. There were two .ipfs directories the second one was in %app data% for Brave… they had the same “PeerID” … I think of the peerID as like a fingerprint or session token.

#18

That’s a bit strange because the private key and peerID are stored in .ipfs/config, which means if you have two unique .ipfs folders, you should have two unique peerIDs.

#19

Unless they created the second one by just copying the first one.

1 Like
#20

I believe that there are(were) two IPFS nodes created on my R340. Kubo was installed I believe after Brave Beta on Server 2022. Only one peerID. Same for a desktop in my homelab that had Kubo and Brave beta. The server was connected through a VLAN switch to the AP. The two desktops were connected through an AR750 router downstream of the AP. After many trials and tribulations I could expect only two could “see” each other and the public remote IPFS peers. The third PC would either only see remote or only local. All of them would only have one peerID.

#21

Indeed.

It’s considered a bad practice to have multiple Kubo instances sharing the same PeerID/Key running simultaneously as it will create race conditions as described in this reply: How to import key to let others publish in same IPNS record - #2 by ylempereur

The main issue is that it “reprovides” the IPNS record every 4 hours. So, if you publish a new record on a node, it provides it. If you later publish to the same address from another node, it provides the new one. But, a bit later, the original node will “reprovide” its own record, walking it back. Then the other will reprovide its record, etc… The more nodes you have, the more they will fight (and only one has the real record at any one time). Also, they each keep the count locally, so multiple nodes will start providing records with the same count, but with different content. In the end, it’ll be a mess.

1 Like