IPNS Public Key Magic

[trans]

Under section 7 of the IPNS documentation this is the example given:

echo "Hello again IPFS" > hello.txt
ipfs add hello.txt

> added QmaVfeg2GM17RLjBs9C4fhpku6uDgrEGUYCTC183VrZaVW hello.txt
> 17 B / 17 B [=====================================================] 100.00%

ipfs name publish QmaVfeg2GM17RLjBs9C4fhpku6uDgrEGUYCTC183VrZaVW

> Published to k51qzi5uqu5dkkciu33khkzbcmxtyhn376i1e83tya8kuy7z9euedzyr5nhoew: /ipfs/QmaVfeg2GM17RLjBs9C4fhpku6uDgrEGUYCTC183VrZaVW

I cannot figure how the system associates the public key with the new file. Nothing here specifies that Qma… is the update for QmU…. All it does is publish Qma… and yet somehow IPFS magically knows it is the new QmU…? Is there something missing here?

[welcome[bot]]

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 additiona 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.

[TMoMoreau]

What are you referencing with Qmu specifically? I don't see any reference to it in the example provided.

[trans]

Sorry. QmU… is the CID first seen in section 3 of https://docs.ipfs.tech/concepts/ipns/#example-ipns-setup-with-cli

[TMoMoreau]

Hi @trans, sorry about the github actions bot demanding more information, not sure what that's about.

Are you still having issues with this concept?

A "name" in IPNS is the hash of the public key, this would be the k51. This k51 key is associated with a record containing information about the hash it links to (the hash it links to is the original CID). This record is signed by the k51 keys corresponding private key. So when the file is updated and you ipfs name publish [New CID], the record is updated and signed by the private key, so the k51 key still knows where to point.

I hope that's helpful (and accurate).

[trans]

Thank you for the response. I must be missing some key notion (lol pun wasn’t intended).

When issuing the following command to publish the modified file…

ipfs name publish QmaVfeg2GM17RLjBs9C4fhpku6uDgrEGUYCTC183VrZaVW

> Published to k51qzi5uqu5dkkciu33khkzbcmxtyhn376i1e83tya8kuy7z9euedzyr5nhoew: /ipfs/QmaVfeg2GM17RLjBs9C4fhpku6uDgrEGUYCTC183VrZaVW

How does IPFS know that the new CID QmaV… is an update for k51? The issued command makes no reference to k51 or the original CID.

I am even further confused by the command…

ipfs name resolve

> /ipfs/QmaVfeg2GM17RLjBs9C4fhpku6uDgrEGUYCTC183VrZaVW

As ipfs name resolve makes no reference to anything! How does it know what it is trying to resolve?

This only seems possible if ipfs is preserving state between calls. Is that it? But that seems very odd for a shell command.

[TMoMoreau]

They don't need to specifically reference anything because you currently only have one k51 key.

You can generate and name a new key using ipfs key gen <key name>. Having 2 or more keys is when you need to start specifying which key to publish to. For example, ipfs name publish -key=<key name> <CID>. Where is the key you want to publish to and <CID> is the updated content you want to publish.

Same idea for the ipfs name resolve. You can specify which key you want to resolve by adding the k51 key to the end of the command. For example, ipfs name resolve <key1> and ipfs name resolve <key2>. Where key1 and key2 represent your 2 unique k51 keys.

I hope this helps, going to close this issue now. If you are still having trouble, you can find all of our community chats and forums here: https://docs.ipfs.tech/community/chat/.

[trans]

Ok I think I understand now. Because the generated keys are being saved to disk and there is only one k51 key, so it just defaults to that.

I think the documentation could use some improvement in this regard. If I find some time I’ll do some experimentation and submit a pull request.

Thanks.