FAQ

An open format for personal AI memory (keepsake/v1) plus a reference implementation: a browser app, a Bun CLI, and an MCP server. A memory is a hashed Cell; a vault is one JSON file holding the cells sealed with AES-256-GCM under a PBKDF2-SHA256 key, with a Merkle root committing to the plaintext.

No. There is no server, no account, no telemetry, and no network code. The CLI reads and writes files on your machine, and the browser app builds the vault in the page. Transport is the file itself.

No. Import, search, seal, and open all run in the tab. Sealing creates the vault in memory and hands it to your browser as a download; the page never posts it anywhere.

Not in the format. The keepsake/v1 container has no embeddings, vector search, or model inference, and the CLI and MCP server recall exactly and lexically, using BM25 over the plaintext cells. The browser app can optionally layer real on-device semantic recall over the same cells without changing the vault; nothing is embedded until you load the model.

No. The embedding model is self-hosted and runs in your browser, so the embeddings are computed on your machine. No memory text, query, or embedding is sent anywhere, and the page makes no network requests.

It is the optional on-device semantic recall model (Xenova/all-MiniLM-L6-v2, quantized). Nothing runs unless you click Load on-device model, and when you do it runs locally in the tab. The site self-hosts the model along with the Transformers.js runtime and the ONNX Runtime Web WASM binaries, so it stays fully offline.

No. Version 0.1 defines a file, not a service or a multi-writer merge. You move a vault by copying the file. Sync, with a documented merge and conflict model, is on the roadmap and would stay opt-in.

keepsake rotate rewrites a vault under a new passphrase: it decrypts the cells and seals them again with a fresh salt and IV. There is still no in-place re-wrap, so the result is a new file with a new ciphertext. There is no escrow and no recovery path, so a lost passphrase means a lost vault.

The container is not encrypted. An observer can see the format version, the creation time, the cell count, the KDF parameters, the exact ciphertext length, and the Merkle root. Version 0.1 does not pad the plaintext. See the security notes in the spec.

Cloud memory lives in the vendor's account: it is not a file you can copy, it is not portable between assistants, and it disappears with the account. keepsake makes the memory a file you own, encrypted at rest and readable by any tool that follows the spec.

Many MCP memory servers keep state in a hosted store or a private database. keepsake's MCP server opens a local vault in process, over stdio, and makes no network calls. You keep the file; the agent only gets a view of it while the server runs.

Yes. The repository ships a composite GitHub Action that installs Bun and runs keepsake verify against a committed vault, failing the job if the passphrase is wrong or any cell hash or the Merkle root does not match. Pass the passphrase through a repository secret (KEEPSAKE_PASSPHRASE), never as a literal. The CLI exit code is the gate: 0 means the vault checks out. See the usage page for the workflow.

A token-budgeted Markdown digest of the cells most relevant to a task, printed by keepsake context and exposed to agents as the memory_context MCP tool. It is a transient projection: it is built on demand from the decrypted cells and is never written into the vault or committed to the format. It is lexical recall, not semantic, and discarding it leaves the vault unchanged.

A memory pack is a plaintext Markdown file that carries a vault's cells losslessly. keepsake pack writes one from a vault, and keepsake unpack verifies its per-cell hashes and Merkle root before sealing it into a new vault. It is agent-readable and integrity-checked, but it is not encrypted: anyone who has the file can read every memory. Treat it as plaintext, and encrypt or omit sensitive cells before sharing.