You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’re trying to set up IPNS and IPNS-Over-Pubsub in helia. The default behavior of IPNS-Over-Pubsub router in helia is to wait to receive the the IPNS update from its gossipsub subscription. But that takes too long, and in Kubo there’s a way for asking a connected peer directly for the latest IPNS record. The difference in terms of latency is huge, helia takes ~30s to resovle an IPNS, while kubo ~2s.
We would like the helia node to fetch the latest IPNS record immediately instead of waiting for IPNS updates in the pubsub topic. The IPNS-Over-Pubsub protocol suggests using Libp2p-Fetch for this, which is what Kubo is using. But we’re hitting a roadblock because no matter how we construct the fetch identifier or key, kubo nodes always respond with NOT_FOUND.
This is how we’re constructing fetch key at the moment. Please let me know how to correct it:
const subplebbitIpnsName = "12D3KooWJ7mvJFaWHK43MYd1Au4W4mkbY7L8dQaiMBqH5bZkSsFn";
const subplebbitIpnsAsPeerId = PeerId.parse(subplebbitIpnsName);
const fetchKey = "/ipns/" + uint8ArrayToString(subplebbitIpnsAsPeerId.toBytes(), "binary");
const res = await helia.libp2p.services.fetch.fetch(peer.id, fetchKey); // always gives undefined because kubo responds with NOT_FOUND
Moreover, is implementing libp2p-fetch for IPNS on the roadmap for helia?
Something weird is happening, after dialing a kubo node with IPNS over pubsub and doing:
libp2p.services.fetch.registerLookupFunction('/ipns/',(key)=>console.log('fetch received with key:',[key]))awaitname.resolve(CID.parse('k51qzi5uqu5dkhvs75chetwlvhwyvhwj8c2qq71tx62z3fekwkms32ubp6k08g').multihash)
Logs:
libp2p:fetch look up data with identifier /ipns/ 퓶U)ǂfzӗఄ筗{;𠴇Rv.ॱ80 +0ms
fetch received with key: [ '/ipns/\x00$\b\x01\x12 퓶U)ǂfzӗఄ筗{;𠴇R\x14v.ॱ80' ]
libp2p:fetch sending status for /ipns/ 퓶U)ǂfzӗఄ筗{;𠴇Rv.ॱ80 not found +1ms
So I assume the key is '/ipns/\x00$\b\x01\x12 퓶U)ǂfzӗఄ筗{;𠴇R\x14v.ॱ80' but when I do:
libp2p:fetch dialing /libp2p/fetch/0.0.1 to 12D3KooWL49bEXmXyp2zVc5HUCjKZjVdavK7mP97Md6qi6HidSUq +0ms
libp2p:fetch using default timeout of 10000 ms +1ms
libp2p:fetch fetch /ipns/ 퓶U)ǂfzӗఄ筗{;𠴇Rv.ॱ80 +36ms
libp2p:fetch received status for /ipns/ 퓶U)ǂfzӗఄ筗{;𠴇Rv.ॱ80 not found +12ms
Using the exact key copy pasted that kubo is sending doesn't work?
Also how does 'k51qzi5uqu5dkhvs75chetwlvhwyvhwj8c2qq71tx62z3fekwkms32ubp6k08g' become '/ipns/\x00$\b\x01\x12 퓶U)ǂfzӗఄ筗{;𠴇R\x14v.ॱ80'?
We’re trying to set up IPNS and IPNS-Over-Pubsub in helia. The default behavior of IPNS-Over-Pubsub router in helia is to wait to receive the the IPNS update from its gossipsub subscription. But that takes too long, and in Kubo there’s a way for asking a connected peer directly for the latest IPNS record. The difference in terms of latency is huge, helia takes ~30s to resovle an IPNS, while kubo ~2s.
We would like the helia node to fetch the latest IPNS record immediately instead of waiting for IPNS updates in the pubsub topic. The IPNS-Over-Pubsub protocol suggests using Libp2p-Fetch for this, which is what Kubo is using. But we’re hitting a roadblock because no matter how we construct the fetch identifier or key, kubo nodes always respond with
NOT_FOUND
.This is how we’re constructing fetch key at the moment. Please let me know how to correct it:
Moreover, is implementing libp2p-fetch for IPNS on the roadmap for helia?
References:
IPNS PubSub Router
The text was updated successfully, but these errors were encountered: