`ipfs name resolve` does not always return the freshest CID for IPNS on Kubo 0.20.0

Help
,
1

With --enable-pubsub-experiment --enable-namesys-pubsub enabled in IPFS 0.20.0, ipfs name resolve does not always return the most recent record I expect. However, if I add the -s option, it returns multiple results, one of which is the most recent one I was expecting. Currently, there seems to be no way to identify the freshness of a record in the CLI/API output. As a workaround, I’ve been using a Redis sorted set to track the first time a CID result appears, but this feels like a hack and I’m looking for a better solution.

2023-06-23 17.31.17
2023-06-23 17.31.171280×260 63.9 KB

In the above example, when I first ran ipfs name resolve , it returned ...xyki , which is an outdated CID for that IPNS. After I added -s , the expected ...aa6m appeared. However, there’s no way to determine from the CLI/API output which one is the most recent.

1 Like
2

After downgrading to Kubo 0.15, following the hints from Kubo versions > 0.15.0 gateway and slow IPNS performance, I am now able to get a stable result from ipfs name resolve immediately after an IPNS is updated to a new CID.

1 Like
3

I think it’d be nice if the verbose output included the sequence field (IPNS Record and Protocol). And then also cache the newest one when it’s seen, ignoring older ones of course. I’m a bit surprised that second point doesn’t already happen…

4

@Jorropo is this a bug?

5
1 Like