MASTR · CRYPTO & WEB3
IPFS and content addressing: authenticity is not persistence
A content identifier helps identify bytes. Someone still has to preserve and serve those bytes.
Chapter text and technical graphics are in English. Navigation is available in seven languages.
Who will still host the file when the original project disappears?
Names and content solve different problems
A conventional location-based URL tells a client where to ask for a resource. A content identifier helps describe which content is requested. If the relevant content changes, its content-addressed identity changes. This can make substitution detectable, but it does not guarantee that any reachable provider still holds a copy. Availability and authenticity remain separate concerns.
A CID is more than a simple file checksum
IPFS can divide files into blocks and organise them in a directed acyclic graph. A CID includes information about how content is addressed; the digest can refer to a root block rather than directly to the entire original file. Different chunking or encoding choices can therefore matter. The statement “the CID is just the file’s SHA-256” is an oversimplification that fails for many ordinary imports.
Pinning is an operational commitment
Pinning tells a node to retain content instead of treating it as disposable cache data under its garbage-collection rules. Local pinning depends on the operator’s storage and uptime; a remote pinning service adds a provider relationship. Several providers can improve resilience, but they should not all secretly rely on the same account, billing arrangement or infrastructure. A promise of permanent storage needs a concrete preservation model.
A gateway adds an access layer
An HTTP gateway can make content-addressed resources convenient for browsers. If one gateway is unavailable or restricts access, the underlying content may still exist elsewhere. Conversely, a working gateway URL today does not prove the content has independent replicas. Record the CID and the original structure rather than saving only a screenshot of one gateway’s response.
Preserve the dependency graph
An NFT’s metadata can point to an image, animation, external site or other resources. Saving only the JSON document can leave the artwork missing. Save the referenced assets and verify that the preserved version matches the intended identifiers. For a research archive, keep dates, source URLs and attribution alongside the bytes. The goal is a reproducible record, not merely a collection of links that once worked.
Worked example
A project pins metadata.json but leaves its image on an ordinary web host. The metadata remains retrievable after the host closes, yet the artwork link fails. Content-addressing one layer did not preserve the next dependency.
Questions to take away
- Keep the content identifier, not only a gateway URL.
- Preserve referenced assets too.
- Verify the actual retention arrangement.