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.

2 Likes

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

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.

I have a related question.

The dag-pb is reachable via the public gateway and is producing the same as Share link:

https://ipfs.io/ipfs/QmaRZ2BJit2oAjMXTrQKticZz6Ef1LyNsjZz44J1YqQfrx

https://ipfs.io/ipfs/bafybeiftrw3rvdejmdijmupouitb2b4sepzsylwtqdmcqk6xhi376m5ree/

But there is a difference between that and the output of Inspect and View on IPFS Gateway which produces:
http://bafybeiftrw3rvdejmdijmupouitb2b4sepzsylwtqdmcqk6xhi376m5ree.ipfs.localhost:8080/

Does anyone know why the second one includes .ipfs.localhost:8080/ and resolves differently than the public gateway?

I’m not quite sure what difference you’re referring to with " there is a difference between that and the output of Inspect and View on IPFS Gateway" but the differences that I’m seeing from what you’ve posted is. the first url is a CIDv0 and the second one is a CIDv1. I can’t tell if they refer to the same content but I’m guessing that they do.

The third url is is rewritten to include the CID as a subdomain to avoid same origin problems and was introduced in IPFS 0.5.0 but was also rewritten to access it through your local node on the standard getaway port 8080.

2 Likes

The third url is is rewritten to include the CID as a subdomain to avoid same origin problems and was introduced in IPFS 0.5.0 but was also rewritten to access it through the your local node on the standard getaway port 8080.

Thanks a bunch! That was spot on. I thought it would solve my CORS issues with pubsub as well but it didn’t work as expected.