IPNS name resolve fails the first time - name.publish and name.resolve are called but works on next call

Wookieleaks · November 17, 2022, 6:41pm

We’ve raised this issue on github but have had no luck solving it. We would appreciate any feedback or suggestions.

IPNS name resolve fails the first time name.publish and name.resolve are called but works on next call

opened 01:47PM - 31 Aug 22 UTC

need/author-input need/maintainer-input

- **Version**: ipfs-core: 0.12.2 libp2p: 0.33.0 libp2p-crypto: 0.19.7  - **Platform**: macOS: 12.4 chrome browser: 104.0.5112.101  - **Subsystem**: IPNS  #### Severity: High  #### Description:  we have forked the js-ipfs repo and have added the functionality to pass an optional secp256k1 private key for creating custom IPNS keypairs. This allows us to create IPNS keypairs that are created from a child derived from a seed phrase giving more control to the seed phrase. The repos modified are ipfs-core, libp2p, libp2p-crypto. We are using a downgraded version since we faced issues using the latest versions then. We have tried using current latest version as well but faced this issue([4148](https://github.com/ipfs/js-ipfs/issues/4148)). the setup has a browser running ipfs-core and is connected to a go-ipfs(kubo) node so that propagation of IPNS publishing works properly. The IPNS name.publish works properly and returns the public key hash but the name does not resolves when resolved via the go-ipfs node and strangely if the same process is repeated twice we are able to resolve the IPNS name. Due to the modifications we can pass the same private key again on the second name.publish call. expected result: the IPNS name should resolve on the first call itself. libp2p-crypto/src/keys/secp256k1-class.js(modified) ``` async function generateKeyPair (bits, optPrivateKey) { const privateKeyBytes = optPrivateKey || await crypto.generateKey() return new Secp256k1PrivateKey(privateKeyBytes) } ``` creating an IPNS keypair ``` const keypair = await this.browserIpfsCore.key.gen(name, { type: 'secp256k1', optPrivateKey: Buffer.from(privateKey, 'hex'), }); ``` IPNS publish using the keypair generated above ``` const resp = await this.browserIpfsCore.name.publish(ipfsCID, { key: keypair.id, resolve: false, // since it mostly fails lifetime: '2400h', }); ``` resolving via the go-ipfs node running on an instance ``` for await (const name of this.ipfsHttpClient.name.resolve(ipnsPubKeyHash)) { cid = name; } ``` modified ipfs-core module w/ libp2p and libp2p-crypto changes: https://www.npmjs.com/package/@mdip/ipfs-core

imthe1 · January 31, 2023, 9:07am

@danieln once an IPNS record is updated can we switch between consistency and availability based on the situation?
right after the record is updated, someone tries to resolve it we would want them to resolve to the latest record with the downside being the resolve might fail but in this scenario consistency is critical and in a normal scenario where someone wants to just persist their IPNS names, having availability will do the job. so is it possible to switch between consistency and availability?

imthe1 · February 8, 2023, 12:01am

to get this working we are publishing and resolving twice where the first resolve basically causes the kubo node to start subscribing to the topic for the IPNS name - as explained by achingbrain on our github issue.

But now we have started observing that if we set the lifetime to a low value such as “12min” or as high as “100day” the record that was published the first time gets resolved even after updating IPNS name to new records multiple times. As per the helpful details & insights shared by @lidel @danieln tinytb we assumed that even though the record has not expired but any new updates to IPNS records will be updated and returned when resolved.

If the expected behaviour is to resolve to the latest record then this might be a bug. Also, if it is supposed to resolve to latest record, means that a user can choose to not have a re-publishing mechanism since longer lifetime can be set when using IPNS with PubSub enabled(thanks to @danieln, tinytb & @lidel for pointing this out). Anyone looking for IPNS persistence over pubsub can set lifetime to a big enough value.

We have enabled PubSub for the above mentioned scenario and are running our IPFS node like so:

ipfs daemon --enable-namesys-pubsub --enable-pubsub-experiment

danieln · February 8, 2023, 10:21am

Does this ever happen after the lifetime of the first record has expired? If so, that is likely a bug.

A couple of things that could be happening here:

For whatever reason the newer record is not properly propagated
when the newer record is created, the nonce isn’t incremented (this would likely be a bug)

I think the best thing to do here as a next step is to create a runnable reproduction repo with as much detail as possible. So that the engineers can take a look at if. Based on our previous conversation, I presume you’re using js-ipfs?

imthe1 · February 28, 2023, 4:28am

hi @danieln

we have created a runnable reproduction repo which can be found here: GitHub - imthe-1/keychain-ipns-sample at debug/lifetime-parameter.

It is basically a react app that does the publishing and resolution and logs it in the console tab inside browser dev tools. we have used chrome browser for running it.

Please do the following to get the code sample working as intended:

Run IPFS node with namesys-pubsub and pubsub-experiment enabled:

ipfs daemon --enable-namesys-pubsub --enable-pubsub-experiment

Please change line #6, 7 at “src/App.js” to match your IPFS node url and its websocket port respectively. it is hardcoded to this currently.

const IPFS_NODE = 'http://localhost:5001';
const IPFS_WS_PORT = 4001;

Run: npm i
Run: npm start

Note: we have tested the above code fragment using kubo v0.17.0 and v0.18.1 and in both the scenarios the 2nd/3rd/4th/… updates via IPNS publish were never resolved. The resolved value was always the first record that we published WHEN lifetime was set to a bigger value, in this case “3day”.
We have modified the standard ipfs-core, libp2p and libp2p-crypto libraries to accept an optional privateKey parameter for secp256k1 IPNS keypairs which allows us to create deterministic IPNS keypairs and names.
While using kubo v0.18.1 the code fragment might throw an error related quic-v1 protocol.

apologies for sharing this late. we ran into issues related to the quic-v1 protocol and could not share it because of this issue. If this is faced at your side, try removing addresses with quic-v1 protocol if possible or we can downgrade to v0.17.0

Please let me know if you face any issues. Thanks!