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: http://ipfs.io/ipfs/bafyreic6x6ekvd3wc56vgol75nfygvav6pxj5raqvdghyqeyxmgcvmx6fy 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 https://ipfs.io/ipfs/< cid > is not working for the CIDs, but the same CID gets reflected, almost immediately, on the IPLD explorer. For example, you can verify: https://explore.ipld.io/#/explore/bafyreic6x6ekvd3wc56vgol75nfygvav6pxj5raqvdghyqeyxmgcvmx6fy

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 https://ipfs.io/ipfs/< 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 https://explore.ipld.io/ 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.

1 Like

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: https://github.com/ipfs/interface-js-ipfs-core/issues/476