A .mem is one file with three parts: a manifest, the media, and an optional timestamp proof. It is built on a standard archive container any platform can open, with no proprietary reader needed, the same choice .docx and .epub made. The media type is application/mem+zip, stored as the first entry so a tool can sniff it from the first bytes.
mimetype "application/mem+zip" (stored uncompressed: a sniffable type marker)
mem.json the manifest (UTF-8 JSON): the contract you parse
README.txt a note for a person who opens the file by hand
media/ the assets (bundled profile only), named by content hash
<sha256>.jpg
<sha256>.mp4
anchor.ots OpenTimestamps proof over manifestHash (optional)The manifest
mem.json is the contract. Everything a reader needs to play, lay out, narrate or verify the memory is in it as UTF-8 JSON: the package, the moments, the people as roles, the order, the presentation hints, the provenance. Chapter 4 goes field by field. README.txt is a note for a person who opens the file by hand.
Media by content hash
Every media file is named by the SHA-256 of its bytes: media/<contentHash>.<ext>. The name is the asset’s identity in the manifest, so a file self-verifies (re-hash it; it matches its own name) and de-duplicates (the same bytes get the same name). Media is stored as-is because JPEG, HEIC and MP4 are already compressed; only the manifest is compressed. A linked file (chapter 8) has no media/ at all; every asset points to where its bytes live.
The anchor
anchor.ots, when present, is an OpenTimestamps proof over the manifest hash. It is folded into the file so the proof travels with the memory and can be checked with no server (chapter 7).
Read order
1. Open the container and read mem.json. If the memVersion major
is newer than you support, degrade gracefully; ignore unknown fields.
2. For each asset, resolve bytes by locator.kind:
embedded -> read ref from inside the file
url -> fetch the URI (see manifest.retrieval on a linked file)
lockbox -> fetch over the lockbox session by handle
3. Re-hash the bytes; compare to contentHash. Reject on mismatch.
4. If provenance.anchor exists, verify anchor.ots against manifestHash.
5. Render from the fields you support.Forward compatibility
Readers must tolerate unknown files and unknown JSON fields. Every addition to the format so far has been additive and optional on memVersion 1.0; a reader that ignores what it does not know keeps working.