# Ever Archive Format 0.1 (Draft)

Ever Archive (`.ever`) is a proposed, open, ZIP-based container for a personal or family memory archive.

## Design goals

- Preserve original recordings, photographs, video, documents, and transcripts.
- Keep the archive understandable without Golden Record or any other account.
- Include enough structured context to make assets discoverable and interpretable.
- Allow integrity verification after copying or long-term storage.
- Contain no executable code, DRM, or encryption requirement.

## Container

An Ever Archive is a ZIP file whose filename ends in `.ever`. An implementation must not rely solely on the extension; it must verify that the archive includes a root-level `ever.json` manifest. The order of entries inside the ZIP is not significant. A person may rename an `.ever` file to `.zip` for manual inspection.

The recommended media type during the proposal phase is `application/vnd.everarchive+zip`. This is a proposed vendor-tree registration, not an IANA-registered media type.

## Required root files

```text
ever.json
README.html
checksums-sha256.txt
```

`README.html` must function without external network requests and describe how to inspect the archive manually. `checksums-sha256.txt` uses the standard `sha256sum` format, one content asset per line. The three required root files are package-support files and are not required to checksum themselves.

## Manifest

`ever.json` is UTF-8 JSON. It must include `ever_version`, `title`, `created`, `subjects`, and `assets`.

Each asset must have a stable `id`, relative `path`, MIME `type`, byte `size`, and SHA-256 `sha256` checksum. Assets may also declare a human-readable `title`, `role`, creation time, and identifiers linking them to source metadata. Paths must use `/` separators and must not be absolute or traverse outside the archive. Implementations must treat external URLs, scripts, and active content as untrusted.

The manifest may include `generator` and `privacy` objects, but a reader must not require a Golden Record account or network request to inspect the package.

## Recommended structure

```text
recordings/                    # original audio
media/photos/                  # original photographs
transcripts/                   # readable transcript files
stories/                       # book, Story Map, and portrait material
metadata/                      # structured source context
```

Implementations may add other folders. Readers must use the manifest rather than assuming every archive has this exact structure.

## Media

Original media must be retained in their source format whenever possible. Access copies may be included beside originals, but must be linked from the asset metadata. The format does not prescribe codecs.

Already-compressed original media should normally be stored without additional ZIP compression. This avoids wasting processing time and does not alter the original bytes.

## Privacy and rights

Implementations may add permissions and rights metadata. They must never imply that the metadata itself prevents a recipient from copying files. Encryption is outside version 0.1; an encrypted transfer should be an outer transport layer, never the sole copy of an archive.

## Versioning

The first field, `ever_version`, follows `major.minor`. Readers must reject unknown major versions with a clear explanation and should preserve unknown fields when rewriting an archive.