How to view ipfs dag CID content from http gateways?

After using the ipfs.dag.put method, received a CID string: bafyreic6x6ekvd3wc56vgol75nfygvav6pxj5raqvdghyqeyxmgcvmx6fy

If I now try this: it does not resolve.

How to view this dag CID content with public ipfs gateways?

1 Like

@KrishnaPG it takes a little more time than we want right now for the network to learn you provide a block. Another thing, is the node that you’re ipfs.dag.put-ing to always online? I can’t see that hash either right now, but if you added it to your local node and your machine is off, then I won’t be able to.

Thank you @michaelavila.

The< cid > is not working for the CIDs, but the same CID gets reflected, almost immediately, on the IPLD explorer. For example, you can verify:

This works:

  1. immediately after the dag.put call (unlike the ipfs gateway url, which never resolves)
  2. even when my node is offline. For example, you should be able to click that link and it should work

The question is:

  1. is the< cid > approach valid? Does it work for DAG CIDs?
  2. why is the IPLD explorer working and IPFS gateway failing, for the same CID?

Here is the screenshot that I now tried (my node is offline, yet the ipld explorer resolving):

HTTP Gateway operates on files, and it expects DAG to be unixfsv1 (dag-pb). This means you should think about HTTP Gateway as ipfs cat instead of ipfs dag get, which works on lower level.

If you want to do ipfs dag get over HTTP, you need to use /api/v0/dag/get?arg=<cid>.

It still works because will fallback to embedded js-ipfs if it can’t connect to your local node.

1 Like

No, dag content fails with an error when loaded via the http gateway

ipfs cat /ipfs/z... unknown node type

That said, i think that is something that could be fixed.


Thank you @lidel and @olizilla.

Looks like the DAG link is working, though it is very very slow than the IPLD explorer.

One point worth considering in this scenario is:

  • knowing the source peerID (from which the block was resolved)

Currently the IPFS gateway or IPLD explorer does not indicated from which peer the block is resolved. For beginners, this kind of information is invaluable in understanding the behavior of these discrete systems.

For example,

  • it is unclear if both IPFS gateway and IPLD explorer resolved the block from the same peer, and if so why IPFS gateway is so slow, while IPLD explorer is almost instant

Related Issue:

Related: feat: serve CBOR encoded DAG nodes from the gateway by alanshaw · Pull Request #8037 · ipfs/go-ipfs · GitHub

the IPLS explorer use the local IPFS node hence it is instantaneous if you create your dag locally… to help the public gateway to learn about a content, I usually put a “fresh” pin on the CID and do a swarm connect to the gateway, followed by a “no-cors” blind fetch HEAD on the public url of the dag.