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?
@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:
dag.put call (unlike the ipfs gateway url, which never resolves)The question is:
https://ipfs.io/ipfs/< cid > approach valid? Does it work for DAG CIDs?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.
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:
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,
Related Issue: https://github.com/ipfs/interface-js-ipfs-core/issues/476
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.
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.