A content identifier, also known as a CID, is a unique value used to identify files stored on the IPFS network. This CID value doesn’t indicate where the value is stored but instead refers to an address based on the content itself. CIDs are generated based on the file or folder’s cryptographic hash, which means:
The same file or folder added to two separate IPFS nodes using the same settings and parameters will produce the same CID.
Any difference in the content, such as metadata differences, will produce a different CID.
The length of the CID will be the same for every file or folder, regardless of the file size or content.
There are currently two different versions of IPFS CIDs - version 0 (0v) and version 1 (v1).
Version 0 (v0)
CIDv0 CIDs are the first format of IPFS CIDs that was part of the initial IPFS design. This version of the IPFS CID uses a base 58-encoded multi-hash to create the content identifier value. This method is simple but isn’t as versatile as the newest CID version, CIDv1. CIDv0 is still the default version for a wide variety of IPFS applications and operations, and it is recommended that you support CIDv0 in any development environment.
CIDv0 CIDs are 46 characters long and always start with the characters “Qm”.
Version 1 (v1)
CIDv1 aims to provide forward compatibility and support different formats that can be used with future versions of the IPFS CID. CIDv1 CIDs include:
A multi-base prefix that specifies the encoding method and format used for the rest of the CID.
A CID version identifier that specifies the version of the CID.
A multi-codec identifier that indicates the format of the content that the CID aims to identify. This helps software and programs interpret the content once the content has been fetched from an IPFS node.
The first few bytes of a CIDv1 CID can be used to interpret the remainder of the CID and provide information about how to decode the content once it has been fetched from IPFS. When To Use CIDv0 vs CIDV1
Currently, new projects are advised to use CIDv1 in their development since this allows the project to be future-proofed, and IPFS plans to set the default CID version to CIDv1 as the new default in the future. CIDv1 CIDs are also safe to use in browser contexts, such as through IPFS subdomain gateways.
When a CIDv0 is accessed with a traditional gateway, the domain will return an HTTP 301 redirect to a subdomain, converting the CIDv0 CID to CIDv1 CID.
For example, opening a CIDv0 resource using a traditional gateway at:
Once a file or folder is uploaded to IPFS and a CID is returned, that CID can be used to access the stored data through an IPFS gateway. All data uploaded to IPFS is public by default since all you need to access it is associated CID. There are no permissions, user accounts, or other security settings tied to IPFS CIDs.
Gateways are used to provide workarounds for applications that don’t natively support IPFS and can also be used as a sharing link for the data. An IPFS gateway can be local, private, or public, and uses the IPFS CID to provide a URL link to the content for access to the stored content.
Filebase's native IPFS gateway is as follows:
All content stored on IPFS through Filebase can be accessed through the Filebase gateway with faster response times than accessing the content through any other gateway. This is because the Filebase gateway peers with our IPFS nodes. The Filebase gateway also peers with the IPFS gateways of other pinning services.
If you are accessing an IPFS Folder CID through the gateway, the contents of the folder will be listed as shown below: