the vault

keep a recording

a recording here is the number that makes a song, with its settings. choose who can open it, then keep it in your vault.

for now your vault lives in this browser only. it is not on the Autonomi network yet.
the recordingreading…
its soundreading…
in your vaultnothing yet
who can open it

ready to keep.

nothing leaves this device until your own Autonomi node is connected.

the comb

reading the vault…
publicprivateprivilegedempty

hold 1.2 s · this browser's store · not the network

vault://manifest · localStorage bmidi-vault

manifest · the vault is this list

store pipeline

    receipt

    verify · no trust in this page needed
    1. localStorage.getItem('bmidi-vault') → the manifest, key by key
    2. address = 4 × 32-bit fold of the stored bytes → 'ant' + 32 hex · a content hash in this page's store, not a network address
    3. private items: first 12 bytes are the AES-GCM iv; only the manifest's key opens the rest
    fork the template ↗ new tab

    the whole vault

    the vault

    record a performance, store it on Autonomi, share it three ways — public (the address is the door), private (encrypted; only your manifest holds the key), privileged (encrypted; you hand the capability to someone chosen). sovereign by construction: the network stores chunks; the keys never leave your device unless you send them.

    0items in the vault
    0 Brecorded bytes
    SIMULATEDstorage backend

    record — a performance becomes an artifact

    publicaddress = the door
    privatekey stays in your manifest
    privilegedyou send the capability

    the score artifact is a few hundred bytes; the WAV render is ~1.4 MB — both store the same way.

    the library — your manifest is the vault

    empty — record something above.

    the backend — simulation today, your node when it answers

    SIMULATED: addresses are content hashes in this page's store — the full flow works (store · send · delete) and the artifact formats are final. When the antd daemon (ant-sdk, REST :8082) answers its health probe, put/get switch to the live network — the daemon's REST routes are not yet documented upstream, so they are verified against a live daemon in one follow-up session, not guessed here. Nothing about your artifacts changes: same bytes, same keys, same manifest.

    Provenance — one self-contained file, encrypted in your browser

    provenance. one self-contained file · encryption is WebCrypto AES-GCM in your browser (per-item random keys; the manifest IS the private vault — export it or lose it, the network will not remember your keys) · addresses are content-derived · delete is honest: it removes your manifest entry — address and key vanish from your device, and without the key the stored chunks are noise to anyone, but the network may keep the bytes · "send" produces a capability line (address+key) — the room's relay lane will carry it signed · simulation backend labelled SIMULATED, never faked as live · no CDN, no build step, zero off-origin.