IPNS resolves to the old CID for some time after publishI

Help
,
1

Hi, I’m trying to bring new life to the git-remote-ipldproject by supporting IPNS. This project still uses go-ipfs-apiand has some issues with kubo-rpc. Nonetheless it’s working flawlessly… except for IPNS…

I’m using ipfs.Shell.PublishWithDetails to publish the new CID to a public key. The problem is that the key still resolves to the previous CID for several minutes after publishing on Kubo 0.39.

Is this expected?

This can cause missing refs on the upstream because the next push may not resolve the public key to the previous CID.

Thank you,

2

IPNS records have a TTL (just like DNS records do), which defaults to 5 minutes. Submit a smaller TTL at publish time if you want a faster response time.

3

I tried with a ttl := time.Nanossecond and got the same result. I was hoping that a 1ns ttl would instantly invalidate the cache, which it didn’t. Is it there a minimum TTL?

I understand the existence of a cache, but I find it odd that the cache is not consistent within the node and don’t get invalidated when a new publish occurs.

4

For super short TTLs, you need to enable --enable-namesys-pubsub when you start your daemon.

5

This combination worked, thank you.

Is it there a reason for a node not to replace it’s cache value when it receives another publish?

6

With pubsub enabled, I believe it does. Without, the node doesn’t receive the update until it goes and looks for it (the update is only sent to the DHT, not to the nodes themselves).