The archive that outlives its software — at1 century

Archives that must last decades outlive the software that wrote them — that’s format rot. A .at1century file is insurance against it: one blob carrying an English description of its own format, the decoder as source in a tiny procedural language, a SHA-256 of the original, and the compressed payload. It reconstructs byte-exact using only what it carries— the embedded decoder run in a bare namespace, no imports, nothing from AT-1 — so it is still decodable when no AT-1 software, or even Python, survives. Any implementer can rewrite the decoder from the paragraph alone.

Use it

# 1) pack a file into a self-decoding container
at1 century pack records.csv -o records.at1century
#   1,142,180 -> 316,069 bytes (3.61x); self-description overhead 1,494 bytes

# 2) read the rebuild instructions it carries, in plain English
at1 century spec records.at1century

# 3) native decoder == embedded decoder, SHA-256 verified
at1 century verify records.at1century

# 4) reconstruct byte-exact using ONLY the embedded decoder, bare namespace
at1 century unpack records.at1century -o out.csv --self-decode

What it guarantees

  • Self-describing — the English spec and the decoder source live inside the file, auditable and rewritable by hand.
  • Two decoders, one answer — a fast native decoder for daily use and the embedded decoder for the guarantee must produce byte-identical output, checked against the SHA-256.
  • No ecosystem required — reconstruction depends on the embedded decoder alone, not on any surviving tool.

The embedded decoder runs in a bare namespace (a few safe builtins, no imports). It’s an integrity and longevity guarantee, not confidentiality — open only archives you trust. For tamper-evidence and right-to-erasure on top of longevity, see the Regulated Archive.

Post-quantum signatures

Longevity has a second failure mode that format rot doesn’t cover. The payloadis fine: AES-256 loses about half its bits to Grover’s algorithm and 128 remains out of reach. The signatureis not — Shor’s algorithm breaks Ed25519 outright, and a signature that can no longer be validated is a certificate that has quietly stopped being evidence. You can re-encrypt data later. You cannot re-sign history: a 2026 certificate re-signed in 2040 proves something about 2040.

So certificates can be dual-signed with SLH-DSA, the stateless hash-based scheme standardised as NIST FIPS-205, alongside Ed25519. A verifier can rely on either, so the certificate stays checkable with conventional tooling today and remains meaningful if the elliptic-curve half falls. Hash-based signatures introduce no new cryptographic assumption — they rest on the same hash primitive the tamper-evidence already depends on.

# inventory: which certificates are still Ed25519-only?
at1 century pq-inventory ./certs

# dual-sign every recognised certificate (writes <name>.pq2.json alongside)
at1 century pq-migrate ./certs

# verify a dual-signed envelope
at1 century pq-verify ./certs/receipt.pq2.json

# erasure certificates: issue one dual-signed from the start (0.1.80+)
at1 erase erase ./store subject-id --signing-key k --out-cert c.pq2.json --pq
at1 erase verify c.pq2.json k.pub --pq-pubkey ./store/_erasure_pq.slhdsa.pub
  • Validated against the standard, not just against itself— the implementation is checked byte-exact against NIST’s ACVP FIPS-205 known-answer vectors. Hash-based schemes have a lot of internal structure and can be subtly wrong while still producing self-consistent signatures.
  • Downgrade-proof— the algorithm suite and both public keys are bound inside the signed body. Stripping the hash-based signature and presenting the result as validly single-signed is rejected, as is an unknown or absent algorithm.
  • Pinning is all-or-nothing— verification refuses an envelope carrying a signer it was not told to expect. A partial pin is an explicit error rather than a silent check of one algorithm.
  • Opt-in, and backwards compatible— existing Ed25519-only certificates keep verifying untouched. SLH-DSA signatures are kilobytes rather than 64 bytes: trivial on a certificate, not trivial on a high-volume signed log, so the choice belongs to whoever knows the retention horizon.

Honest scope: this protects the signatureon evidence you keep for decades. It is not a claim that every artefact we emit is dual-signed by default — it is opt-in, and for erasure certificates it arrived in @tinyfiles/cli@0.1.80. We wrote up how we found that gap, including the fact that we had the capability for three weeks without a way for anyone to reach it, in what a deletion certificate proves.

← CLI reference