What fixity actually means (and why we put it on the homepage)

When we started building Vault, the first decision we made — earlier than the storage vendor, earlier than the AI search, earlier than the visual design — was that the product had to be able to prove every file in it was still the file you uploaded. That requirement has a boring archival term: fixity. I want to talk about it, because it's the difference between an archive and a folder of files that probably still work.

What fixity is

Fixity means a file hasn't changed. Not the metadata. Not the name. Not the modified-at. The bytes. If you uploaded a 47-megabyte RAW from a Canon body in 2019, fixity means we can prove — not believe, not hope — that the 47,341,824 bytes sitting in storage today are byte-for-byte the same 47,341,824 bytes that left your laptop.

The way you prove it is with a cryptographic hash. Run SHA-256 over the file when it's uploaded, write the hash down, and any time you want to know whether the file is still intact, run SHA-256 over it again and check that the two hashes match. If they match, the file is the file. If they don't, something changed. You don't know what, but you know the archive can't be trusted until you fix it.

The fact that we can detect a single flipped bit in a 47 MB file using a 256-bit number is one of the more honest miracles of modern computing. It's the same trick git uses, the same trick blockchains use, the same trick TLS uses. It works.

The thing photographers actually care about

Photographers don't say "fixity." They say things like: "Are you sure the file is still good?" That's the same question. They've been burned by a corrupted RAW exactly once, ten years ago, and they remember it. They're asking whether the thing in storage is the thing they uploaded.

What they don't know — and what most cloud storage vendors are quiet about — is that the answer is usually "we hope so." Storage at the vendor level does its own integrity checking, usually via background scrubbing and erasure coding. Backblaze, S3, GCS — all of them do this. Most of them are very good at it. But the proof exists at the vendor level, not in your hands. If you ask Backblaze "is this file still intact," they say yes because their scrubber said yes. You're trusting them. You have no record you could verify against.

That gap — between the vendor's proof and the customer's proof — is what fixity at the product layer closes.

How we do it

Three places in the pipeline, all of them visible in the UI:

1. Browser-side, at upload. We stream the file through crypto.subtle.digest("SHA-256", ...) in the browser as you upload. The hash is computed before the file leaves your machine. It goes into the database alongside the file's row. That moment — the moment you click upload — is the canonical "what we agreed the file is." Everything after that is checking against this number.

2. Server-side, at finish. When the upload completes, we re-hash the object from object storage. If it matches, the file's verified_at timestamp flips on and you see a green check. If it doesn't, the upload is rejected and the row is rolled back — you'd see the file as a failed upload, not a quiet corruption. This is the moment a missing or flipped byte during the network transfer would show up.

3. In the background, forever. Roughly every 90 days, a worker picks files and re-verifies their hash. Mostly it confirms what we expect. Occasionally it flags something for review. That number — the count of files whose hash has been re-checked recently — is exposed on the project page as part of the trust UI. It's not a thing we want to hide.

The reason I'm putting this in a blog post is that none of this is exotic. The components are all standard. The cryptography is forty years of research at this point. What's unusual is doing it visibly, at the product layer, where the customer can see it and audit it. You can ask Vault: "show me the manifest for this wedding." You get a list of every file in the project, its hash, when we last verified that hash, and the result. That's it. The archive either is intact or it isn't, and you can tell.

Why we put it on the homepage

There's a green dot next to most file rows in Vault. It looks decorative. It's not — it's the indicator that the file has been verified within the policy window. We could have hidden the indicator and exposed it only on a "trust" page somewhere. We chose to put it everywhere, because the whole point of a verifiable archive is that verification is a property of the file, not of a separate screen.

The same reasoning is why "verifiable backup" leads the homepage. We're not trying to sell the cryptographic hash. We're trying to sell the property — that the archive is real, and you don't have to take our word for it.

What this doesn't fix

Fixity catches bit-level corruption. It does not catch: a file that was deleted on purpose by you, a file that was overwritten before upload, a file that was never uploaded in the first place. For deletions we keep a trash window with restores. For overwrites we keep the original as a separate object until the user explicitly confirms a replacement. For missing files, we run a manifest reconciliation against what your camera card actually contained. Those are separate problems. None of them are fixity. All of them matter, and all of them get their own posts.

The point I keep coming back to

The thing I want photographers to be able to say — about whatever tool they end up using, Vault or not — is "I have a backup, and I can prove it." Most working photographers, today, can say the first half. The second half is rare. Fixity is what makes it possible. Putting the proof in the customer's hands, in a way they can verify, is the part of the work I'm most proud of so far.

We'll keep writing about the rest. This one was the foundation.