← vault manual
Afterberry Vault

Photographic Carriers

Revision 2.0 — 20 September 2026. Profiles AB-R1 and AB-C1.

§E1 The photographs as infrastructure

The 8 Museum is a collection of photographs of the numeral 8 found in the world. Its founding collection is the first 8,888 entries of the museum’s register, completed on 2 September 2026. The register continues; later entries are not carriers. The carrier files themselves have not yet been made — they are finished at the ceremony, when the shards they describe exist — and this page specifies what each will be.

Each founding photograph is paired with one shard of the vault and will carry, in the least significant bits of a thousand of its samples, an 88-byte record for that shard. The visible picture and the invisible record are two readings of one object. Nothing about the picture gives the record away, and nothing about the record is secret: the method is published here, the positions can be computed by anyone, and the record’s contents are public facts about public ciphertext. The photographs are hidden in plain sight — art that is also infrastructure — but what they hide from is the eye, not the analyst.

§E2 What a photograph carries — record AB-R1

BytesField
0–3“AB8R”
4profile version (1)
5flags — bit 0: a sealed key is present; bit 1: rehearsal
6–7photograph number, 1–8,888
8capsule number, 1–101
9shard number, 1–88
10–11reserved, zero
12–51the capsule’s sealed key Wc (40 bytes), or zero
52–83SHA-256 of the shard file
84–87CRC-32 of bytes 0–83

That the record comes to exactly 88 bytes is a courtesy of the arithmetic. Photograph i is paired with capsule c = ((i − 1) mod 101) + 1 and shard s = ⌊(i − 1) / 101⌋ + 1.

The sealed key is the capsule’s content key wrapped under a key that does not exist until the lock yields (Sealing §S6). It is useless today and to anyone who cannot open the lock, which is why it can ride in a public photograph. It is also the single most loss-critical datum in the vault — without Wc an opened lock opens nothing — and so it is the datum replicated most widely: in every one of the capsule’s 88 shard headers, in the capsule inventory, and in 88 photographs spread evenly across the collection. The photographs are keys. Sealed ones.

Photographs paired with Remainder capsules carry no key, because there is none. Their records hold a digest and nothing else: a headstone rather than a key.

§E3 Protection

The record is extended to a 128-byte codeword by a Reed–Solomon code: GF(28) with polynomial 0x11D and α = 2; generator ∏i=0…39(x − αi); systematic, the 40 parity bytes following the record, with byte 0 of the record as the coefficient of the highest power. Any 20 damaged bytes among the 128 are corrected; the CRC catches what the code miscorrects. The codeword is 1,024 bits, embedded most significant bit first.

§E4 Canonical carriers

The museum’s website shows WebP images made for looking at. Those are exhibition derivatives and carry nothing. A carrier is a specific PNG file:

FormatPNG, truecolour, 8 bits per sample, non-interlaced, sRGB
ChunksIHDR, sRGB, iTXt (keyword “afterberry”), IDAT, IEND
File digestSHA-256 and SHA3-256 of the file
Pixel digestSHA-256 of width ‖ height (four bytes each) ‖ the decoded RGB samples in row order

Canonicalisation is done once. The source photograph — HEIC or JPEG from the capturing phone — is decoded with its orientation applied, colour-managed into sRGB, reduced to 8 bits, and written as PNG. The tools and versions are recorded for provenance, but the conversion does not need to be reproducible and is not claimed to be: canonical means these bytes, fixed by their digest. The sources themselves are preserved inside the vault.

The two digests answer different questions. The file digest says whether this is the very file that was sealed. The pixel digest survives any lossless re-encoding — a different compressor, a future format — and says whether the picture, and therefore the record, is intact.

§E5 Embedding — profile AB-C1

Number the samples of a W × H image s = 3(yW + x) + channel, with red 0, green 1, blue 2, so that there are N = 3WH of them.

1 — SeedS = SHA-256(“afterberry/AB-C1/” ‖ photograph number (2 bytes) ‖ W (4 bytes) ‖ H (4 bytes)).
2 — StreamBlock j of the stream is SHA-256(Sj as 8 bytes), j = 0, 1, 2 … Each block is read as four big-endian 64-bit integers.
3 — PositionsTake integers v from the stream. Each proposes the sample v mod N. Discard any sample already chosen. Stop at 1,024. The order in which samples are chosen is the order of the codeword’s bits. An image with fewer than 8,192 samples is not a carrier.
4 — WritingOnly once all 1,024 positions are fixed, visit them in order. If a sample’s least significant bit already equals its codeword bit, leave it and draw nothing. Otherwise draw the next integer from the stream and move the sample by one level: up if the integer is odd, down if even — except that 0 always moves up and 255 always moves down.
5 — DuplicateWrite the 128-byte codeword, as 256 lower-case hexadecimal characters, into the iTXt chunk: keyword “afterberry”, uncompressed, language tag and translated keyword empty.
6 — VerifyDecode the finished file from disk, extract, and compare. A carrier that has not been read back is not a carrier.

On average 512 samples change, each by one level. In a twelve-megapixel photograph that is one sample in seventy thousand, at an embedding rate below 0.00003 bits per sample. The reduction v mod N carries a bias smaller than 2−35 for any image under a hundred megapixels, which matters to nobody and is mentioned for completeness.

The positions depend only on the photograph’s number and dimensions, never on its pixels. That is the property that makes extraction exact: the reader computes the same positions from the same three numbers, whatever the writer did to the samples. Content-adaptive schemes — S-UNIWARD (Holub, Fridrich and Denemark, 2014) with syndrome-trellis coding (Filler, Judas and Fridrich, 2011) — are better at evading a steganalyst, and would be the right tool if the record were a secret. It is not. What the record needs is an extractor that a stranger can reimplement from one page of prose in an unknown century, and a hash function and a modulus meet that need where floating-point wavelet costs do not.

§E6 Extraction, and what survives what

To read a carrier: decode the PNG to 8-bit RGB with no colour management, compute the positions from the photograph’s number and dimensions, read one bit from each, Reed–Solomon decode, check the CRC.

What happened to the fileEmbedded recordiTXt copy
Copied byte for bytesurvivessurvives
Re-encoded losslessly, metadata keptsurvivessurvives
Re-encoded losslessly, metadata strippedsurviveslost
Retouched or cropped in place, saved as PNG with metadatadamaged or lostoften survives
Resized, colour-converted, or saved as JPEG or WebPlostusually lost

The two copies fail under different insults, which is the reason for having both. And no photograph is a single point of failure: every record is also written out in the signed catalogue, its sealed key is in all 88 of the capsule’s shard headers, and its digest is in the capsule inventory. A photograph that has lost its record is still a photograph.

A record is protected against damage, not against forgery; anyone can compute a CRC. A record is believed because it agrees with the signed catalogue, or with many independent copies of itself — and a sealed key needs no vouching at all, since a false one simply fails to unwrap.

§E7 The carrier catalogue

The catalogue is a plain text table, one line per photograph: number, museum register identifier, capture date, dimensions, file digests, pixel digest, capsule, shard, and the 88-byte record in full. It is signed at the ceremony (Preservation §R7), travels with every replica, and is printed in the bootstrap kit. Together with the records inside the photographs it lets a future reader establish, from either direction, which pictures belong to the vault and whether they are intact.

§E8 Handling

  1. Move carriers as files, never as images. Verify the file digest at the destination.
  2. Never resize, rotate, crop, colour-correct, re-save or “optimise” a carrier. Make a derivative for that and keep the carrier.
  3. Never serve carriers through anything that processes images on the way: CDN optimisers, photo libraries, social platforms, messaging apps.
  4. Keep the catalogue beside the carriers.
  5. When in doubt, extract. It needs no key and harms nothing.

§E9 The rehearsal carrier

rehearsal-carrier.png is a synthetic 888 × 888 image — it is not a museum photograph — carrying a record for rehearsal capsule 1, under photograph number 0, which is reserved for rehearsal. Rehearsal capsules are not sharded, so the record’s digest field holds the SHA-256 of the capsule file, standing in for a shard.

A large green numeral 8 on a dark ground: the rehearsal carrier.

Extractpython3 afterberry_ref.py carrier-extract rehearsal-carrier.png --index 0
Pixel digestc003945116a9039475cec0b05268bb5352f10668f697f3efbb5a180d0b37a8cc
Record41423852010300000101000063e95a904af21b6ff5eb618c39ab07e0d0567f3ae3c4a197b2adcae7641c4d833d2ecb693190f5e8345a40e78b40c8db556c02b4ad7b0b87004d8d0d0fc4ae2148389d1f2b0037550a37b5ba
Samples changed510 of 2,365,632

The sealed key in that record is the one in the rehearsal lock file, and opens with it. The tool reads and writes PNG itself, implements the Reed–Solomon decoder in full, and depends on nothing outside the Python standard library.