Different behavior between kubo.dag.get and explorer webui

I have a Helia node which is adding content with heliadag.add(object). It is connected to Kubo node in an asymmetric way (Kubo is in Helia peers but Helia is not in Kubo peers).

I have a Kubo node who I am requesting this object to, with kubo.dag.get(cid).then(console.log) using the js-kubo-rpc-client. This function does not return, I can wait for a while, like 20 seconds, nothing happens.

But as soon as I go the the webui of my Kubo node, enter the same cid in the search bar, and click the “inspect” button:
my function logs the object.

So I am wondering: which API call does this inspect button trigger that is not triggered by the kubo.dag.get() call? Why is Kubo retrieving the content when I ask it through the UI but not from the API directly?

This doesn’t really make sense. Connections are bi-directional.
If the Helia node is in Node.js they should be able to establish a connection of TCP overwhich Bitswap should be able to exchange blocks.

Strange. Do you have Bitswap enabled on the Helia node? Is the Helia node running in Node.js?

The IPFS Web UI uses the local gateway exposed by Kubo to retrieve blocks.

If it’s loading the block successfully via the UI but not with js-kubo-rpc-client it means that Kubo is likely able to fetch the block (from the Helia node), so it sounds like a problem with the RPC API or the way the RPC client is instantiated.

1 Like

I think the same, that’s why I omitted to specify that the Helia node was running on browser and connected with websocket or webtransports depending on what’s available (can’t wait for webrtc in go ^^).

Can you maybe share the JS code you are using to call kubo.dag.get() and the version of GitHub - ipfs/js-kubo-rpc-client: A client library for the Kubo RPC API you are using?

1 Like

To answer this more directly, the explore page in ipfs-webui (and ipfs-desktop) is available more directly at https://explore.ipld.io/ and the code is at GitHub - ipfs/ipld-explorer-components: React components for https://explore.ipld.io and ipfs-webui.

GitHub - ipfs/ipld-explorer-components: React components for https://explore.ipld.io and ipfs-webui was updated a while ago to use trustless-gateways for fetching blocks, and then migrated to use @helia/http.

explore.ipld.io can also be configured in two ways:

  1. ipld-explorer-components/src/lib/init-helia.ts at cd3ffcaf3e11b7d9e0cb9a77a13de7c32e8906c6 · ipfs/ipld-explorer-components · GitHub
  2. ipld-explorer-components/src/bundles/helia.ts at cd3ffcaf3e11b7d9e0cb9a77a13de7c32e8906c6 · ipfs/ipld-explorer-components · GitHub

ipfs-webui & ipfs-desktop use the configured kubo node for the kuboGateway config option.

The code that actually does the fetching used to be directly in ipld-explorer-components/src/lib/get-raw-block.ts at master · ipfs/ipld-explorer-components · GitHub, but is now abstracted away by the NetworkedStorage component of Helia, which we use with a simple helia.blockstore.get in this file now.

Ok, so you mean that the explorer is not based on the kubo rpc API only but embeds a full IPFS Helia node? That means if I open a large file in the explorer, it will be present twice: first in my local Kubo node and second in the Helia node of the explorer. I did not expected that.

I added links to source in your quote.