Turning the page.
Bringing the next chapter into view…
Psst… make reading your own.
Fonts + themes live in Appearance. Your eyes get a vote.
Bringing the next chapter into view…
Identifying data through a cryptographic digest and representation information so retrieved bytes can be checked independently of their storage location.
Checking this browser’s read-aloud support…
A location-based address points to a place that can serve different bytes over time. IPFS content identifiers instead incorporate a digest and information about the data's representation. A client can use the identifier to check the block it receives regardless of which peer supplied it. That check relies on the chosen hash function's security and correct decoding; the identifier does not contain the original file or promise that a peer is online.
IPFS documentation also corrects a frequent shortcut: a CID is not generally the SHA-256 checksum of the original file. Files can be chunked, encoded and arranged in a linked structure whose root receives the identifier. The same file imported with different settings can therefore produce different CIDs. In a reproducibility exercise, record the chunker, codec, layout and CID version alongside the input. Comparing only two visible CID strings without understanding those settings cannot establish that the underlying human-readable documents are different.
UnixFS specifies how files and directories are represented in IPFS using raw blocks and structured nodes. Larger files can span linked blocks, while directory nodes associate names with links. Reading a path requires interpreting that structure, not merely downloading a single root object. A valid root block is useful evidence about its links, but it does not mean that every linked block has been retrieved.
Build a toy archive containing a lesson, an image and a bibliography. Draw a directory node linking to each file, then split the image into two blocks. Delete one image block from the imagined provider. The root and lesson may still verify while the complete archive cannot be reconstructed. Next change only the bibliography: the graph shows which parent links must change and which unchanged blocks can be reused. This exercise separates structural integrity from completeness.
For an actual archival test, walk the required graph and open the reconstructed files; a check that stops at the root misses the failure the exercise exposes.
An immutable identifier is awkward for a website that publishes new editions. IPNS supplies a stable name with a signed record pointing to a content path. The corresponding private key can publish a new record, and records carry information including sequence and expiration. The name therefore authenticates an update authority while the referenced CID identifies one particular version of the content.
Imagine a class syllabus changes from revision A to revision B. Keeping the IPNS name in a bookmark helps readers find updates; recording A's CID in a citation preserves the version used in an assignment. These serve different purposes. If the naming key is compromised, an attacker can redirect the name without breaking the integrity of either old or new content. If record distribution is delayed, readers may encounter different versions. For evidence that must remain reproducible, preserve the resolved content identifier and the retrieval context instead of citing only a changeable name.
The Trustless Gateway Specification defines responses containing raw blocks or content-addressed archive data that a client can verify. It separates this from asking a gateway to deserialize content and simply trusting the returned file. The word trustless describes an integrity-checking interface, not a guarantee of speed, privacy, availability or universal browser support. A client must actually perform the required verification to obtain that benefit.
For a practical test, imagine a gateway substitutes one block during a download. A verifying client should reject bytes that do not match the requested graph. Now imagine the gateway returns nothing: hashing cannot solve that availability problem. Finally, provide a correctly hashed but malicious document. Integrity verification should succeed because the bytes are authentic to the identifier; it does not certify the document is safe or true.
A complete reader distinguishes transport failure, integrity failure and untrusted content, allowing each to be handled without overstating what the content address proves.