After using the
ipfs.dag.put method, received a CID string:
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.
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
- immediately after the
dag.put call (unlike the ipfs gateway url, which never resolves)
- even when my node is offline. For example, you should be able to click that link and it should work
The question is:
- is the
https://ipfs.io/ipfs/< cid > approach valid? Does it work for DAG CIDs?
- 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
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:
- 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.
- 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
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:
But there is a difference between that and the output of Inspect and View on IPFS Gateway which produces:
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.