This explains why you got different CIDs, when uploading a file to IPFS (or more factually adding the file to an IPFS node). There are various parameters while adding the file. So of them are chunk size, type of leaves, type of Tree, number of maximum children. These factors affect the generated CID. In your case, it seems like the one you received from Fleek (which I suppose is of multicodec ârawâ) might have used âRaw Leavesâ, and one from Pinata might have used âUnixFS Leavesâ.
This occurs due to differences in performance of pinning service providers and is not related to the multicodec of a CID.
It is not just possible, because a change in multicodec also means change in the underlying data, which ultimately will result in different hash. When hashes are different then those two pieces of data are not the same. When using UnixFS Leaves, we will have some more information, which might not be present in raw leaves. It means that the underlying data has changed and thus the CID. So, just changing the multicodec part of the CID wonât work, because it would result into invalid CID.
But, I would assure you that, if 2 CIDs are indeed pointing to same thing, then IPFS would find them appropriately.
To test it
Hereâs your CID
bafybeieb3fsnggzs35rhxqsfoqaohtykbwxt4tesbrmwm5cstsoc6vmyxu
Hereâs the CID version 0 of the same CID
QmX5XZps24BizVepAGSVbS38ytHXtLmAiSZ2iZbSvcQ5cQ
When you input both of the CIDs in cid.ipfs.io, you can see that âDigestâ are same. So regardless of which version you are using, even though the CIDs look different and have different version IPFS can find the data, because they have the same content.
Extra:
While I tried to convert the second CID to CID version 0, I wasnât able to do so, because CIDv0 only supports âdag-pbâ nodes.
So, now we have more insights on why was the CID different, seems like Fleek uses CIDv0 and Pinata has moved to using CIDv1.
If you have any further questions feel free to ask.