https://ipfs.io/ipfs/bafkreih5aznjvttude6c3wbvqeebb6rlx5wkbzyppv7garjiubll2ceym4
What’s going on here exactly? Let’s break it down. First you have the gateway domain. There are lots of different domains out there, like ipfs.io
, and if you have a Pinata account you get a Dedicated Gateway which might look something like aquamarine-casual-tarantula-177.mypinata.cloud
. Each of these can be used to bridge files from IPFS to HTTPs. Next you have the IPFS path which looks like ipfs/
and this is necessary for a gateway to work. Finally we have the CID at the end, which is the actual IPFS address for our content.
Folder Paths
Sometimes your CID might be a folder, in which case you might have difficulty loading it through the gateway. This happens because if you do not designate a complete folder path, then the gateway will try to load all of the files and index them into a sheet showing every file. This can be pretty intensive depending what kind of gateway you’re using, and will likely stall out due to how long it can take. To remedy this, simply add on the file path of the content you’re trying to get inside. For instance, if we have a folder with the CID ofQmWfHgs3nKiyFWx3tFEYvm8DiHTrCsxEHxvDdBh95ZQSLT
and the inside looks something like this:
/pinnie.png
or clouds.json
to the end of our folder path. In the end we would have something like this.
Public Gateways
The most common kind of IPFS Gateways are Public Gateways. These are usually run and maintained by IPFS Pinning Services, protocols, or even smaller groups that want to help build the IPFS ecosystem. They’re referred to as “Public” because anyone can access them! You just have to add a CID to the end of one to start using it. You can try that now by adding this CIDbafkreih5aznjvttude6c3wbvqeebb6rlx5wkbzyppv7garjiubll2ceym4
to the end of a Public Gateway:
Public Gateways are not meant for production apps, be sure to only use them for testing!