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.
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 ^^).
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.
