.akr files to store and share setup sections, overlay themes, HUD labels, and control-display presets. An .akr file is a ZIP archive containing one manifest and one main payload. StartPos and Whole setup packs with saved slots also contain one shared snapshot bundle. The reader accepts only manifest.json, the main payload required by the archive kind, and StartPos attachments declared by setup.json.
Archive shape
Exports write compact manifest and setup JSON and use maximum DEFLATE compression for JSON entries. StartPos slots share onestartpos/snapshots.bin.br entry stored
without further ZIP compression. A bounded dictionary shares repeated byte chunks;
a reversible base64 transform removes text overhead before Brotli quality 11,
window 24. Every original snapshot JSON byte survives unchanged.
snapshotBundleSha256 covers the compressed bundle. Each slot’s
snapshotSha256 covers its raw JSON document. Local StartPos saves continue to use
gzip; export does not rewrite them. Imports validate each document and save it
through the normal local snapshot writer. The byte-level contract is documented in
docs/reference/snapshot-bundle.md.
Pack creation runs in the background because maximum compression can take minutes
on large maps. The completed archive replaces its destination atomically. Uploads
and downloads transfer those compressed bytes directly. A downloaded pack with the
catalog’s exact size and SHA-256 is reused on subsequent imports. Existing cloud
objects do not shrink until replaced with new exports.
Most archives contain two entries. StartPos and Whole setup archives with saved slots add one shared entry:
The reader rejects undeclared entries, rooted paths, backslashes, empty path segments, and . or .. path segments, as well as archives that do not match the expected payload name and kind.
Manifest
Themanifest.json file uses the following structure:
The manifest must contain exactly these fields, including both fields in
target. Missing, extra, differently cased, or null fields are rejected. The
manifest size limit is 16 KiB.
Current archive kinds
Every current kind uses manifest
kindVersion 1. The payload format has its own version and is validated before Akron applies imported state.
Payload contract versions
The archive container (akron-archive, formatVersion 1, kindVersion 1) describes
the ZIP shape and the manifest. It is independent of what a payload means, and it does
not change when a payload contract changes.
The current portable and local contracts are:
A StartPos snapshot records an object graph with map identities, ownership
edges, live-resource identities, and structural paths into a clean room reload.
Reconstruction checks those relationships before applying saved state. A change
to required captured state or baseline assumptions requires a new snapshot
version; the filename carries that version too. The setup payload version
changes independently when the pack’s own contract changes.
The contracts also move when a snapshot has to carry something it did not carry before.
A snapshot records, next to each saved object, whether the name it was saved under is
one any install can look up again and whether the map laid that entity out. A snapshot
written without those cannot be checked against them, so it is refused rather than read
with a weaker guarantee under the same version number.
Akron does not convert older payloads. A pack whose payload format is not the current
one is refused when it is read, before any attachment is opened, and the message names
both contract versions. A snapshot whose document format is not the current one is
refused by the reader, before the reconstruction path sees it.
Setup payload
Setup packs use thesetup archive contract:
state omits its required fields:
buttonBindings and menuActionBindings are present
only for Keybinds and Whole. startPositions and snapshotBundleSha256 are
present only for StartPos and Whole. The bundle hash is empty when there are no slots. The payload createdUtc value must exactly match the
manifest createdAt value.
The setup payload size limit is 2 MiB.
The compressed bundle is limited to 509 MiB, leaving room under the 512 MiB
community-download limit. Each expanded v12 snapshot is limited to 384 MiB,
and all expanded snapshot documents together are limited to 1 GiB.
Export accepts local gzip sources up to 128 MiB each and 509 MiB in total.
A StartPos or Whole archive can contain at most 99 StartPos entries.
Each slot key must be in the range 1-99.
The public upload service has narrower resource limits: 32 MiB per archive and
384 MiB of expanded snapshot JSON across the whole pack. Split larger packs
before uploading. Catalog previews use the existing JPEG conversion with a 2 MiB
cap. Published private upload sources become eligible for cleanup after 24 hours;
the approved public pack and images remain stored.
Portable setup validation limits
Akron applies these limits when it writes or reads a setup pack. Values outside the ranges are rejected rather than clamped during pack validation.
Required strings cannot be empty or whitespace. Optional strings can be empty,
but cannot exceed their listed length.
Every enum field must contain a defined named string value. Each StartPos entry
must use the archive name
startpos/snapshots.bin.br and a 64-character
lowercase hexadecimal SHA-256 digest of its original JSON bytes.
Setup sections
Setup packs preserve machine-local values: the screenshot export path;
recording output folder, filename template, replay auto-start mode, and
colorspace arguments; audio-splitter state and device selections; and the Auto
Deafen hotkey. Whole exports omit these values too.
Scoped imports replace the selected portable settings without resetting
unrelated settings. A StartPos import also replaces every StartPos slot for the
archive’s target map. Slots for other maps remain unchanged.
Import safety rules
Imports follow a “fail closed” policy: Akron rejects archives with unsupported formats or versions, incorrect kinds, missing or extra entries, oversized payloads, invalid JSON, or unsupported payload formats. Setup packs created beforeakron-setup-v10 cannot be imported. Older StartPos snapshots, including v11, must be captured again, then their packs re-exported with the current build.
Akron verifies the compressed bundle hash and each document’s checksum, map,
and room before applying the setup. It then binds the snapshot to the recipient’s
active save-file slot. The exported attachment contains the captured active
map’s berry progress, but import replaces that field with the recipient’s
current active-map berry progress before binding the snapshot. Akron does not
import the author’s progress or module save data.
If an import fails, current settings remain unchanged. Akron shows a short toast and writes the detailed error to its logs.
Maintenance requirements
Settings included in.akr setup packs must meet these requirements:
- Must be defined as a field in
AkronSetupState. - Must support capture from
AkronModuleSettings. - Must support application back to
AkronModuleSettings. - Must implement scoped-section copy behavior when the setting belongs to
StartPos,AutoKill,AutoDeafen,Recorder,Audio, orHud. - Must have automated tests proving whole import/export and scoped import/export preserve the intended state.
- A unique manifest
kind, payload entry name, payload format string, and payload size limit. - Dedicated single-payload archive helper methods.
- Simple payload entry names (e.g.,
labels.json). - Unsupported payload-format rejection before state is applied.
- Tests for round-trip behavior, wrong kinds, extra entries, oversized payloads, and missing manifests.
- An update to this page that documents the complete contract.
.akr archive. The current contract requires exactly one kind, one manifest, and one main payload. Only StartPos snapshot attachments declared by setup.json are allowed.
Archive tests live in tests/archive-tests.cs.