Your AI knows you.
Nobody else does.
ApertoMemory is an open format for AI memory: everything your assistant has learned about you, sealed in a file that is yours - encrypted with your keys, signed, portable to any compatible tool. Switch AIs and it still remembers you.
Each cell is one byte of a real sealed memory from the format's test vectors - a user preference, signed and encrypted. This grid is everything a storage server ever sees of your memory.
$ amem export my-memory.amem # on your old machine $ amem import my-memory.amem # on the new one ✓ 6 objects imported - all signatures verified
Memory is the new lock-in.
Every AI tool builds a memory of you inside its own walls. Switching tools destroys it - a lock-in that operates on your personal data, not on price. ApertoMemory makes memory a thing you own and carry. Other portability efforts move your memory in cleartext; ApertoMemory never does.
Encrypted before it leaves your device
Content, authorship, and semantic timestamps are sealed client-side. A sync server is a blind blob store: it cannot read, index, or correlate what it holds.
Every memory proves who wrote it
Objects are signed inside the encryption, and the signature is bound both to the author's key and to the object envelope. An object cannot claim an authorship it cannot prove, so third-party memories are cryptographically distinguishable from your own - a built-in defence against persistent prompt injection.
Your whole memory in one file
Export everything as a single .amem file - a complete vault
fits in kilobytes. Import it into any compatible tool and every signature
verifies.
A protocol, not a product
A CDDL schema, machine-readable test vectors, an MIT reference
implementation in Python, a second and independent implementation in
TypeScript - both conformant to the same test vectors - and an IETF Internet-Draft
(draft-ferro-apertomemory). Anyone can implement it;
no company controls it.
Seal. Carry. Open.
Sign, then encrypt
A memory is signed with your Ed25519 key, then encrypted under a single-use key wrapped to your identity. Keys derive from one passphrase; per-scope keys keep your coding tool out of your personal memories.
One file, anywhere
Export your entire memory as one .amem
file. New device, new AI tool - with your passphrase, everything opens.
Your AI already knows you
Through the MCP adapter, any MCP client reads your vault - Claude Desktop, Claude Code, Gemini CLI, Cursor. Same file, different vendors. They read it directly. Import on a fresh machine, ask a question - the answer already fits you.
Not a memory engine.
Engines like Mem0, Supermemory or Zep are the intelligence
layer: they decide what to remember - extracting facts, ranking,
retrieving. ApertoMemory is the layer underneath: it decides who owns
the memory. One is a brain, the other is a vault. The best future is
engines that export .amem: their intelligence, your custody.
Memories on our servers
Not because nobody uses this - because there are no servers. And any server you choose for storage or sync sees only ciphertext. The big number every memory service shows you is the number of memories they can read.
Install in ten seconds.
# Python (reference) - requires Python 3.10+ - CLI: amem, format: .amem $ pipx install apertomemory # or pip, inside a venv # with the MCP adapter - Claude Desktop / Claude Code / Gemini CLI / any MCP client $ pip install "apertomemory[mcp]" # TypeScript - Node 20+ and browsers $ npm install apertomemory
Building a compatible tool?
Start from the CDDL schema and the test vectors. Conformance is not just reproducing bytes. Six of the fourteen vectors are refusal cases: a forged authorship, a rewritten envelope, a version downgrade, a custody record signed by someone other than the vault owner. An implementation that reproduces every byte and refuses none of these is not conformant - it is the bug the vectors exist to catch. The TypeScript implementation was written against these vectors alone, without reading the Python reference, and the disagreements between the two uncovered three defects - one of them in the reference itself. Questions and spec review belong in the issues.
Questions you should ask.
What happens if I lose my passphrase?
Your memories are gone. There is no recovery, no reset email, no support ticket - because nobody else holds keys that can decrypt them. That is not a missing feature: it is the price of a design where no provider can read your memory. Treat the passphrase like the key it is.
What does a storage or sync server actually see?
Ciphertext, opaque identifiers, object sizes and timing patterns. Not the content, not the author, not semantic timestamps. Sizes and timing are real metadata leakage and the spec says so plainly instead of marketing around it.
How do I search my memories?
Client-side, after decryption. A server that could search your memories could read them - so this format deliberately has no server-side search. Your tools decrypt your vault locally and search there.
Is this an alternative to Mem0, Supermemory or Zep?
No - different layer. Those are memory engines (what to remember,
how to retrieve it). This is a memory format (how it is protected,
owned and moved). An engine could store or export its memories as
.amem; nothing would make us happier.
Has the cryptography been audited?
Not yet, and every page of this project says so. The primitives are standard and well-reviewed (Ed25519, AES-256-GCM, Argon2id, AES-KW); the composition is exactly what we want adversarial eyes on. If you break something, SECURITY.md explains how to tell us.
How does this relate to GDPR?
The export file is a working implementation of Article 20 data portability - and unlike most, it does not leak your life in transit. Cryptographic erasure (destroying the key wraps) is a clean implementation of the right to erasure.
I'm Andrea Ferro, an independent developer in Verona, Italy. Everything I release follows the same rule, which I call No Walls: free, open, no paywalls, no lock-in. I did it with a DNS protocol that now ships in OpenWRT routers, with security plugins running on 100K+ WordPress sites, and now with the thing I care most about: your AI's memory of you should be yours to carry. If you think I got something wrong, the spec and the issues are open.