Text2Store's product pages make one claim more legally loaded than the rest: that an archive can prove it has not changed since the day it was made. This chapter is the engineering behind that sentence, and more interestingly, the three dilemmas it forced. Readers of the buyer-facing pages (court, RSMF, the screenshot essay) see the conclusions; here is how they were reached.
The hole that started it
Every archive carries a manifest of SHA-256 hashes for its files. That catches corruption, but during an internal security review we wrote down the obvious attack: edit the message database, regenerate the manifest, and the archive is self-consistently forged. Self-consistent is not the same as untampered. Anything we did about it had to work for an audience of skeptical lawyers, without betraying the product's core posture: no server of ours holding user data.
Dilemma one: a server would be easy, and wrong
The obvious fix is escrow: upload each archive's hash to our server at creation, and later ask us to confirm it. Rejected. It creates infrastructure we must run forever, it makes us a required trust anchor (the whole point is that nobody should have to trust us), and it plants a timeline of user activity on our side. The alternative is older and better: RFC 3161 trusted timestamps. At backup time, a fingerprint of the manifest (32 bytes, never message content) goes to an independent timestamp authority, which signs it with the time and returns a token stored beside the archive. Anyone can later verify, offline, with standard tools, that these exact bytes existed no later than that date. No server of ours, no account, nothing to keep running.
Dilemma two: the free authority or the credible one
The first implementation used a free community timestamp authority, and it worked. Then we asked the question that actually matters: who reads this proof? A lawyer, an opposing expert, a judge's clerk. "Signed by DigiCert" and "signed by a hobbyist service" verify identically in the math and completely differently in the room. We switched to DigiCert's TSA before shipping, and the switch was real engineering, not a URL swap: their tokens carry a multi-hop certificate chain, which forced a bounded chain-walking verifier in Rust and surfaced two genuine parsing bugs on the way (a CMS digest-algorithm assumption that RFC 5652 permits breaking, and an unread optional field in BasicConstraints). A second adversarial review then caught that our verifier never checked the pinned root's own validity window, and that DigiCert ships two same-named roots, self-signed and cross-signed, which broke our issuer lookup. Cryptographic verifiers earn their trust the boring way.
One discovery from that work made it into the product's own documentation: the LibreSSL that ships with macOS cannot verify these token chains at all, even given the correct root. The verification instructions we ship say so and point at real OpenSSL, because "check it yourself" instructions that fail on a stock Mac would be worse than none.
Dilemma three: the claims you refuse to make
The feature's power is bounded by honesty, and three boundaries were drawn on purpose:
- Never retroactive. Certification happens at capture or not at all. Timestamping an old archive today only proves it existed today, which is the exact misuse the feature invites. Refusing "certify later" costs us support tickets and buys the claim its meaning.
- Two-tier precision. Every attachment in a verified export is provably byte-identical to the timestamped backup. The readable transcript is different: it is text we extracted from that backup, so the honest claim is "extracted from a backup proven unaltered since date X", never "the transcript matches the phone." We say the smaller thing because it is the true thing, and it is the version that survives cross-examination.
- Proof and production stay separate. RSMF, the eDiscovery format, deliberately carries no integrity claim, and we dropped an early idea of embedding it inside the verified export. A review platform wants complete, flagged data (RSMF includes deleted-and-recovered messages, marked); a skeptical recipient wants a checkable record (the verified export). Fusing them muddles both jobs. The buyer pages now teach that distinction because the architecture enforces it.
Where it landed
Certification is on by default at backup, sends only a fingerprint, and cannot be added after the fact. Verified exports carry the token, per-file hashes, and instructions an opposing expert can run without our software. RSMF output is gated on Relativity's own published validator on every change to the writer. And the marketing pages are forbidden, by standing policy, from saying "court admissible", because that is a court's decision, and a claim we refuse to sell is the reason the claims we do sell hold up.