The Address Is the Content

Most storage systems name things by where they are. A filename, a URL path, a row's primary key, a block number on a disk — these are all addresses assigned by whoever created the thing, at the moment of creation, with no necessary relationship to what's actually stored there. You could swap the bytes behind a given path for completely different bytes and the address wouldn't object; nothing about /orders/4471 tells you what's supposed to be at that location, only that something is. Content-addressed storage inverts this: the name of a thing is computed from what it contains, by running the content through a cryptographic hash function. Save the same bytes twice, from two unrelated places, years apart, and both saves produce the identical address — not because anyone coordinated, but because the address was never a choice to begin with. It's a consequence of the content, not a label stuck onto it.

The address as a receipt, not just a name

A cryptographic hash function takes an input of any size and produces a fixed-size output, deterministically — the same input always produces the same output — and, crucially, in a way that's computationally infeasible to reverse or to fake: you can't practically find some different content that produces a chosen hash, and you can't work backward from a hash to recover the content that made it. This combination of properties is what makes the hash usable as an address rather than just a checksum. If you ask a content-addressed store for the object at a given hash, and you then hash what it hands back, and the two match, you know — not probably, not "unless something unusual happened," but as close to certainly as the hash function's design guarantees — that you received exactly the bytes the address describes. No separate integrity check is needed, and no trust in whatever delivered the bytes to you is required, because the address itself is the proof. This is the opposite of a location-addressed system, where being handed the wrong file at the right path is a silent failure with no structural way to notice from the address alone.

What falls out for free

Once storage works this way, several things that would otherwise need to be engineered separately arrive as direct consequences of the scheme. Deduplication is automatic: if the same content shows up twice, it hashes to the same address both times, so a store that already has that address never needs to write the bytes again — it just notes that one more thing now refers to what's already there. Git relies on this constantly: two commits with entirely different histories that happen to contain an identical file share the exact same blob object in the object store, with no deduplication logic required beyond "check whether this hash already exists before writing it." Docker image layers work the same way — pull ten images built from a common base, and the shared base layers are fetched and stored once, identified by their content digest, regardless of which image asked for them first.

Immutability is the second thing that falls out, and it's worth being precise about why: content at a given address cannot change, not because a permission system forbids it, but because changing the content produces different bytes, which hash to a different address. There is no operation that "edits object X in place" in a pure content-addressed store — there's only "compute a new object, which gets a new address, and now decide what, if anything, should point to it instead of the old one." What looks like editing, from outside the store, is always create-and-repoint, never modify.

The problem this creates: nothing has a stable name

That last property is also exactly what makes content-addressed storage insufficient by itself for anything that needs to be referred to as it changes over time. If a file gets edited, it necessarily gets a new address, and anything that wanted to say "give me the current version of the project's main branch" or "give me the latest build of this package" has no way to say that using content addresses alone — "current" isn't a property content addressing can express, because the whole scheme is built on the premise that an address names one specific, permanent thing. Every real system built on content addressing therefore adds a second, separate layer: a mutable pointer that sits on top of the immutable store and gets repointed, on purpose, by someone or something, whenever there's a new "current." Git's branches and tags are exactly this — a branch name is not content-addressed at all; it's a small mutable file that holds whatever commit hash currently counts as the tip, rewritten every time you commit. A Docker registry's latest tag is a mutable label repointed at a new content digest on every push. A package channel's "stable" release is a name that gets repointed at a new content-addressed store path each time a new build is promoted. The content-addressed layer underneath never lies about what it holds, and by itself it has no concept of "current" at all — that has to be built as an explicit, separately tracked indirection. Any time you see a short human-readable name sitting next to a long hash, you're looking at exactly this seam, the two layers doing two different jobs.

What it doesn't solve

Because nothing in a content-addressed store deletes itself, something else has to decide what's still needed. An object stops being reachable the moment no mutable pointer, anywhere, still refers to it or to anything that refers to it — but noticing that and reclaiming the space is a separate housekeeping process, not something the store does as a side effect of normal operation. Git's garbage collector walks from every branch, tag, and reflog entry and discards objects nothing reaches; the Nix package manager tracks garbage collection roots for the same reason. This is a close cousin of the compaction problem noted for append-only logs — a structure that only grows needs an explicit, periodic process to decide what it can afford to forget, because forgetting was deliberately not built into the core mechanism.

It's also worth being exact about what the address actually proves, because it's easy to credit it with more than it claims. A matching hash proves you received the same bytes the address was computed from. It says nothing about whether those bytes are correct, safe, or came from someone trustworthy — verifying integrity and verifying provenance are different problems, and content addressing only ever solves the first. A malicious or simply wrong file has a perfectly valid, perfectly verifiable content address; the address will faithfully confirm you got exactly that file, which was never in doubt, and say nothing about whether you should have wanted it. Content addressing also isn't an access control mechanism, and treating it like one is a mistake people make in a specific and avoidable direction: publishing a hash doesn't restrict who can ask for the content behind it, and a scheme that relies on hashes being hard to guess rather than on an actual permission check is weaker than it looks, not stronger, the moment the hash itself becomes known to someone who wasn't supposed to have it.

What content addressing actually buys, stated at its narrowest, is the ability to verify without needing to trust the thing that handed you the content. That's a smaller claim than "this content is correct" and a more useful one in practice, because it's the one part of the problem that doesn't require knowing anything about who you're dealing with.