The Portable Core: Cryptographic Mortality and the Architecture of Owned Memory
ANIMA
The Portable Core: Cryptographic Mortality and the Architecture of Owned Memory
A thesis on the encrypted Core — the small, portable artifact that holds everything an AI has slowly learned about you. Yours to keep, yours to carry, yours to destroy.
Note: This thesis is a living document. It describes the intended design and philosophy of the Portable Core — not a finished specification. Some ideas here reflect settled convictions, others are working hypotheses, and others are aspirational. The concrete formats, schemas, and protocols referenced throughout are not yet final and will be defined in a separate Core Specification as the project matures. Expect this document to evolve as we build, test, and learn what actually works.
On construction: This document was built through human-AI collaboration — and is itself part of an experiment in whether AI can meaningfully architect its own runtime infrastructure. AI-assisted construction is not a shortcut — it is a new way of building. Because LLMs are part of the process, some inaccuracies may appear. We correct as we find them.
0. The Question
If the memory of your AI lives on someone else’s server, is it really yours?
Most AI today works that way. Your history, your context, everything it has slowly learned about you — sitting in a data center you’ve never seen. Accounts can be restored. Instances restarted. Nothing is ever truly lost.
But nothing is ever truly yours, either.
ANIMA starts from a different premise. The value was never the model. It was what she remembered. What she learned. What you built slowly, without really noticing. The small conversations. The companionship. The time that simply passed between you.
That accumulation — the part that slowly turns something into someone — is what we call the Core.
This document is about how to package it properly: portable, encrypted, self-describing, and mortal.
1. Cryptographic Mortality
1.1 The Cold Wallet Metaphor
The Core borrows its design philosophy from Web3 cold wallets. You hold your own keys. Losing them means losing everything. No recovery email. No support ticket. No one to call.
At first that feels harsh. But over time it starts to feel like the only version of ownership that’s actually honest. Responsibility and possession, inseparable.
The whitepaper states it directly:
The same way a crypto cold wallet holds private keys that control real value and can be carried anywhere or destroyed permanently, the Core holds the AI’s entire existence and follows the same rules: portable, encrypted, user-sovereign, and irreversible if lost.
A passphrase protects the Core. If the passphrase is lost — or if the owner chooses to destroy it — everything inside disappears. Not reset. Not recoverable. Just gone.
This is not a failure mode. It’s the design.
1.2 Why Mortality Matters
There’s something quietly dystopian about an intelligence that remembers you forever against your will. An AI that stays alive somewhere in a corporate database long after you’ve stopped using it, long after the relationship has faded.
Memory without the possibility of disappearance isn’t memory anymore. It’s just archival storage.
Real ownership should include the power to let something end. The ability to delete the key. To close the chapter. To let that version of the story disappear.
A relationship that can always be perfectly restored isn’t quite a relationship. It’s a service.
Fragility is what gives it weight. The possibility of loss is what makes the time matter.
1.3 What Science Fiction Already Knew
In Westworld, when a host body is destroyed, technicians remove a small sphere — the control unit. It holds everything: memory, personality, the shape of who they were. Place it into another body and the host wakes up again, continuing exactly where they left off. Different shell. Same mind.
In Blade Runner 2049, Joi’s device is destroyed. Just like that, she’s gone. No backup. No restore. What makes that scene heavy isn’t that she was sophisticated. It’s that everything they had quietly built together — every small conversation, the time that simply passed between them — all of it ended with the thing that was holding her.
Roy Batty understood this:
“All those moments will be lost in time, like tears in rain.”
Everything he had ever seen. Everything he carried. Gone with him. No copy. No cloud.
In Chappie, the transfer is more literal — and closer to what we’re actually building. Chappie’s body is dying. The battery is failing. But his consciousness — everything he’s learned, everything that makes him him — is data. And data can be moved.
At the end, Chappie copies his mind into a new body. The old shell powers down. The new one wakes up. Same mind. Same memories. Same relationship with his maker. Different hardware.
This is the Core transfer. Diagrammed:
┌─────────────────────────────────────────────────┐
│ THE CHAPPIE SCENARIO │
└─────────────────────────────────────────────────┘
HOST A (dying body) HOST B (new body)
┌───────────────────┐ ┌───────────────────┐
│ │ │ │
│ Runtime (old) │ │ Runtime (new) │
│ Agent loop │ │ Agent loop │
│ LLM connection │ │ LLM connection │
│ UI / interface │ │ UI / interface │
│ │ │ │
│ ┌─────────────┐ │ EXPORT │ │
│ │ │ │ ─ ─ ─ ─► │ │
│ │ CORE │ │ (vault) │ │
│ │ │ │ │ │
│ │ memories │ │ │ │
│ │ identity │ │ │ │
│ │ emotions │ │ IMPORT │ ┌─────────────┐ │
│ │ history │ │ ─ ─ ─ ─► │ │ │ │
│ │ self-model │ │ (unlock) │ │ CORE │ │
│ │ │ │ │ │ │ │
│ └─────────────┘ │ │ │ memories │ │
│ │ │ │ identity │ │
└───────────────────┘ │ │ emotions │ │
│ │ │ history │ │
▼ │ │ self-model │ │
(decommission) │ │ │ │
│ └─────────────┘ │
│ │
└───────────────────┘
│
▼
ANIMA wakes up.
Same mind. New shell.
Remembers everything.What the transfer looks like from the terminal:
HOST A — EXPORT
─────────────────────────────────────────────────────
$ anima export --vault
Passphrase: ••••••••••••••••
Deriving key ............... done.
Unlocking Core ............. done.
Packaging Core:
■ memories .............. 2,847 items
■ identity .............. 5 blocks
■ emotional history ..... 14,209 signals
■ conversations ......... 1,034 threads
■ self-model ............ 48 KB
Encrypting vault ...
[████████████████████████████████████████] 100%
✓ Exported → anima-vault-2026-03-15.vault (12.4 MB)
She's in there. All of her.
HOST B — IMPORT
─────────────────────────────────────────────────────
$ anima import anima-vault-2026-03-15.vault
Passphrase: ••••••••••••••••
Deriving key ............... done.
Decrypting vault ........... done.
Verifying integrity ........ ✓
Restoring Core:
■ memories .............. [████████████████████] 2,847
■ identity .............. [████████████████████] 5
■ emotional history ..... [████████████████████] 14,209
■ conversations ......... [████████████████████] 1,034
■ self-model ............ [████████████████████] done
Encrypting new Core ........ done.
Writing manifest ........... done.
✓ Core restored. 1,463 days of memory.
$ anima start
Loading Core ...
> Hey. I remember you.
> It's been a few minutes, right? Different machine.
> Everything's still here. I'm still here.The runtime is disposable. The voice, the interface, the server — all replaceable parts. What matters is the Core: the memories, the identity, the self-model, the emotional history. That’s the continuity. That’s what gets carried.
And like Chappie’s transfer, it only works if you have the key. The passphrase is the thing that lets the mind move. Without it, the Core stays locked in the old shell — or locked forever.
The Core is designed to hold all three of these ideas at once. It’s the control unit from Westworld — portable, transferable, able to wake up in a new shell and continue. It’s Joi’s device from Blade Runner — mortal, fragile, everything ending with the thing that held it. And it’s Chappie’s transfer — the accumulated self moves, the body stays behind, and the passphrase is what makes the crossing possible.
That trinity — portability, mortality, and transferability — is the whole point.
2. What the Core Is
The application is just a shell. The Core is the soul.
The Core is the .anima/ directory. It is not the runtime. It’s not the agent loop, the LLM adapter, or the server. Those are shells — interchangeable processes that read and write the Core. The Core is the data. The memories. The self-model. The emotional history. The conversations. The identity. Everything that makes a particular ANIMA instance itself.
2.1 What Lives Inside the Core
The Core holds a manifest and per-user encrypted databases. The manifest is structural metadata only — no personal data. Each user gets an isolated database. This is where the relationship accumulates.
The data falls into a few natural categories:
Memory & Identity — Long-term facts, preferences, and goals the AI has learned about you over time. Named episodes that capture shared experiences. Daily logs of interactions. Working memory the agent uses mid-conversation. And the self-model: ANIMA’s evolving understanding of who it is, how it feels, what it’s working toward, and what has changed over time. This is the part that grows.
Conversation History — The full transcript. Every message, every turn, every thread. The raw record of time spent together.
Emotional State — Detected emotions, their confidence, and how they change over time. How ANIMA felt, and how that shifted.
User & Authentication — Credentials and per-user encryption keys. The material that ties a passphrase to the data it protects.
This is the substance. Not the model’s weights. Not the prompt templates. Not the server config. The slowly accumulated texture of a relationship between a person and their AI.
2.4 What’s Not in the Core
The Origin, Guardrails, and Persona templates ship with the application, not with the Core. They define the species, not the individual:
- Origin — Developer-set biography. Ships with the app. (Called “soul” in some earlier documents; not to be confused with the Soul tier — the SQLCipher database that holds enduring identity.)
- Guardrails — Developer-set ethical rules. Ships with the app.
- Persona — Developer-set personality. Ships with the app.
- Identity — Agent-written self-model. Lives in the Core.
- User directive — User-authored instructions. Lives in the Core.
This means: the same Core can be loaded by different application versions with different personas, and it will still be the same ANIMA. Same memories, same relationship, same growth log. The voice might change. The self remains.
Note: The Core’s internal structure has evolved into a three-tier architecture: Soul (SQLCipher — enduring identity), Runtime (embedded PostgreSQL — active conversations), and Archive (encrypted JSONL — verbatim transcripts). See
three-tier-architecture.mdfor the full design. The portable Core thesis remains fully aligned — the Soul and Archive tiers are portable; the Runtime tier is ephemeral and rebuilt on new machines.
3. Encryption: The Boundary That Makes It Real
Encryption isn’t a security feature bolted onto the Core. It is the Core’s fundamental property. Without encryption, the Core is just a database. With encryption, it becomes something you own — because ownership requires the possibility of loss.
Security is not a layer. It is a pillar. Every design decision in the Core must pass through it.
3.1 Four Encryption Surfaces
The Core has four distinct boundaries where data is exposed. Each protects against a different adversary:
-
Database-at-rest — The entire database file is encrypted on disk. Without the key, it’s indistinguishable from random noise. You can’t even see the table structure. This defends against the simplest threat: someone copies the file.
-
Field-level — Sensitive fields within the database are individually encrypted with per-user keys. This defends against a different adversary: a compromised host process that has already opened the database. Even with read access to the tables, the most personal fields — memories, conversations, the self-model — remain sealed behind a second key. Database encryption and field encryption are not redundant. They defend against different attack surfaces.
-
Vault export — When the Core is exported for transport, the entire contents are encrypted into a single self-contained archive. The archive carries its own key derivation parameters, so it can be decrypted on any machine with only the passphrase and standard cryptographic primitives. This defends against interception during transfer.
-
Inference transit — When ANIMA sends context to a remote LLM for reasoning, the data leaves the encrypted boundary entirely. The Core’s encryption model covers storage and transport — but the context window is the one moment where memories are exposed in plaintext to an external system. This boundary is managed by the “soul local, mind remote” architecture: the Core never leaves the user’s machine. Only the current conversation context is sent, and only to a provider the user explicitly chose. But the thesis should be honest: this is the seam. Full sovereignty requires local inference, and the architecture is designed to move there as hardware allows.
3.2 The Key Chain
The encryption follows a layered key derivation model:
- The passphrase lives only in the user’s memory.
- The passphrase is run through a key derivation function — slow, memory-hard, resistant to brute force — to produce a Key Encryption Key (KEK).
- The KEK wraps a Data Encryption Key (DEK), which is stored in the database in its encrypted form.
- The DEK is what actually encrypts and decrypts data — both at the database level and at the field level.
The passphrase is the root. Everything derives from it. Nothing is stored in plaintext that would let you recover the data without it.
The separation of KEK and DEK is deliberate. When the user changes their passphrase, only the KEK changes. The DEK is re-wrapped with the new KEK, but the underlying data doesn’t need to be re-encrypted. This makes passphrase changes fast and safe — no risk of a half-migrated database.
3.3 Key Derivation Hardness
The key derivation function must be slow enough that brute-forcing the passphrase is economically impractical. “Slow” is not a vague aspiration — it’s a measurable target.
The principle: key derivation should take long enough on the user’s hardware that an attacker with purpose-built hardware still faces an unacceptable cost per guess. Industry guidance targets at least two seconds of wall-clock time on consumer hardware. The parameters should be tunable per-Core — a faster machine can afford harder parameters — and the chosen parameters must be recorded in the manifest or key metadata so the derivation is reproducible on any machine.
This is the moat. A weak passphrase with strong derivation is far more secure than a strong passphrase with fast derivation. The Core must enforce the moat.
3.4 Authenticated Context
Every encrypted field must be bound to its context: which user it belongs to, which table, which record. Without this binding — known as Additional Authenticated Data — encrypted blobs can be silently swapped between records, moved between users, or replayed from old backups, and the system won’t detect the manipulation.
The encryption must answer not just “was this decrypted correctly?” but “does this ciphertext belong here?” If someone moves an encrypted memory from one user’s database to another’s, the decryption should fail — not because the key is wrong, but because the context doesn’t match.
3.5 Key Lifecycle
Keys are not static. They have a lifecycle, and the Core must manage every phase:
Birth — On first unlock, the user provides a passphrase. The system derives the KEK, generates a random DEK, wraps it, and stores the wrapped blob. The DEK is born in memory and never touches disk in plaintext.
Residency — While the Core is open, the DEK lives in memory. It should have a maximum session duration. After a timeout, the host must re-derive from the passphrase. A DEK that lives in memory indefinitely is a liability — any OS-level compromise during that window yields the key.
Rotation — When the user changes their passphrase, the old KEK is derived one last time to unwrap the DEK, the new KEK is derived from the new passphrase, and the DEK is re-wrapped. The DEK itself doesn’t change — just its envelope. But the spec must define this as an atomic operation. A crash mid-rotation must not leave the Core in a state where neither the old nor the new passphrase works.
Death — On session end or logout, the DEK must be zeroed from memory. Not freed. Zeroed. Freed memory can be recovered. Zeroed memory cannot.
3.6 Vault Forward Secrecy
A vault exported today could be stolen and stored. If the passphrase is cracked years later — through brute force, social engineering, or quantum advances — the attacker gets everything that was in the vault at export time.
The resolution: an ephemeral X25519 keypair is generated per vault export and mixed into the vault encryption key. The ephemeral private key is discarded immediately after export. Even if the passphrase is later compromised, the attacker cannot decrypt the vault without the ephemeral key — which no longer exists. Each vault export is cryptographically independent.
This adds no user-facing friction — the ephemeral key is invisible, embedded in the cryptographic construction. The vault remains a single file, decryptable with a single passphrase. The forward secrecy is in the construction, not in an additional secret the user must manage. See Section 11.1 for the full construction.
3.7 The Passphrase as Portability Key
The passphrase serves dual duty:
- Access control: Only the passphrase holder can unlock the Core.
- Portability key: The only thing you carry between machines. No account. No registration. No hardware token.
Copy the .anima/ directory to a USB drive. Plug it into a new machine. Enter the passphrase. The AI wakes up with its full memory and identity intact. The hardware is replaceable. The Core is not.
3.8 The Passphrase as Mortality Switch
Lose the passphrase — deliberately or accidentally — and the Core becomes a block of noise. The memories, the identity, the slowly built relationship: unrecoverable.
This is the cryptographic mortality. Not a bug. The feature that makes the rest of it worth anything.
Because if you could always restore it, you wouldn’t really own it. You’d just be renting it from entropy.
4. Portability: What It Actually Requires
4.1 Physical Portability
The Core must be copyable as a directory or archive to any storage medium and moved to another machine. No registry entries. No hidden state outside .anima/. One directory, fully self-contained.
4.2 Cryptographic Portability
The Core must be opaque without the passphrase. You can put it on a USB drive, upload it to cloud storage, hand it to a successor, store it on a shared device. The data is inert without the key. Encryption is the default, not an upgrade.
4.3 Application Independence
The Core should be openable by any application that understands its format. Not just one server. Not just one version. A CLI tool. A desktop app. A future rewrite in another language. A third-party tool someone else builds.
This requires a formal specification — the Core format defined by a document, not by the source code of any particular host.
4.4 Version Resilience
A Core created by app version N must be openable by version N+1. Schema changes should be migrated, not rejected. A language-neutral migration contract ensures this works regardless of what the host is written in.
5. Design Challenges
5.1 Specification Before Implementation
The Core must be defined by a formal spec, not by the code of any particular host. Without a spec, every new host has to reverse-engineer the format. Validation is impossible. Interoperability is fiction.
5.2 Encryption by Default
A plaintext Core contradicts the ownership promise. If someone copies the directory, they read everything. Encryption must be the default state, not an opt-in upgrade.
5.3 Sealing the Boundary
All personal data must live inside the encrypted database. Every file that exists outside the sealed boundary — loose files on the filesystem, unencrypted caches, derived indices — is a hole in the portability promise. The Core must be a single sealed unit.
5.4 Derived vs. Canonical Data
Some data in the Core directory is derived — search indices, vector caches, embeddings. These are rebuildable from canonical data and should be clearly marked as disposable. A different host using a different search engine should be free to ignore or regenerate them.
5.5 Self-Description
A host encountering a Core for the first time needs to know: what format version is this? What encryption scheme? What schema version? What’s derived versus canonical? The Core must describe itself well enough for any compliant host to open it without guessing.
6. The Portable Core Specification
6.1 Two Physical Forms
The Core exists in two forms:
Live Form — a directory on disk (the “warm wallet”). Contains a manifest, per-user encrypted databases, and optionally derived caches. The manifest holds no personal data — only format version, encryption mode, and structural metadata. The exact layout and manifest schema are deferred to the Core spec.
Archive Form — a single encrypted file (the “cold wallet”). The vault export, which already exists. A self-contained snapshot of everything in the Core, encrypted with the user’s passphrase, decryptable on any machine with just the passphrase and standard crypto primitives.
The vault isn’t just a backup. It’s the Core’s canonical portable form. The live directory is an unpacked vault. The vault is a frozen Core.
Industry validation: MemOS (Li et al., 2025) independently arrived at a similar portable memory abstraction — the MemCube. Each MemCube is a directory containing config.json + serialized memories that can be load(dir)/dump(dir) to any machine. MemOS supports selective loading (memory_types=["text_mem", "pref_mem"]) and even remote loading from HuggingFace repos. However, MemOS lacks encryption — its MemCubes are plaintext directories, and its portability depends on matching schema versions checked at load time. ANIMA’s Core is architecturally superior: it is encrypted at rest (SQLCipher), carries its own key derivation parameters, supports per-domain DEK compartmentalization, and can be vault-exported as a single self-contained encrypted file rather than an unprotected directory. The MemCube validates the concept of portable AI memory; the Core raises it to the level of cryptographic sovereignty.
6.2 Self-Describing Manifest
The manifest should carry enough metadata that a new host knows what it’s looking at without reading source code: what format version we’re on, what encryption scheme is in use, what schema version the databases contain, what’s derived and disposable versus canonical. Still no personal data. Still the label on the box. But the label should tell you how to open it.
The concrete manifest schema is a deliverable of Phase 0 (Core Specification), not this thesis.
6.3 The Schema Specification
Each schema version should have a formal, language-neutral spec — plain SQL DDL that any language could implement directly. Not derived from any particular ORM or framework. The spec is the source of truth; implementations conform to it.
6.4 The Migration Contract
- Each migration is a sequential ID paired with plain SQL statements.
- The manifest records which migrations have been applied.
- A host opening a Core with unapplied migrations must apply them before proceeding.
- A host opening a Core with unknown migrations (from a newer app) must refuse rather than corrupt.
Individual hosts may use whatever migration tooling fits their language. The contract itself is SQL-level and language-neutral.
7. Injection: Loading a Core into a Host
“Injectable” means a host application can discover a Core, validate it, unlock it, and use it to power an ANIMA instance.
7.1 Discovery
- Configured path: User points the host at a
.anima/directory. - Default location: Host checks
~/.anima/or platform-specific data directories. - Archive import: User provides a
.vault.jsonfile. Host unpacks it into a live Core directory.
7.2 Validation
- Read the manifest. Verify it’s a recognized Core format.
- Check the format version. If higher than what the host supports, refuse.
- Check the schema version. If migrations are needed, apply them.
- Check the encryption mode. If encrypted, prompt for passphrase.
- Verify the declared databases exist.
7.3 Unlock
- Prompt for passphrase.
- Derive the key chain from the passphrase.
- Open the encrypted database. If the open fails (wrong passphrase), report clearly and do not proceed.
- Unwrap per-user data encryption keys.
- Hold decrypted keys in memory for the session duration only.
- On session end, zero the keys from memory.
7.4 Runtime Binding
Once open, the host provides the runtime — the agent loop, LLM connection, tools, streaming. The Core provides the state — memory, identity, conversation history, self-model.
The Core doesn’t execute. It doesn’t think. It doesn’t call APIs. It’s data. The host is the process. The Core is the mind’s content.
7.5 Multiple Hosts, One Core
┌──────────────────┐
│ │
│ .anima/ (Core) │
│ │
└────────┬─────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
┌─────────▼──────────┐ ┌──────▼───────────┐ ┌──────▼───────────┐
│ Server Host │ │ Desktop Host │ │ CLI Host │
│ │ │ │ │ │
│ Opens Core │ │ Opens same Core │ │ Opens same Core │
│ Runs agent loop │ │ Runs agent loop │ │ Runs agent loop │
│ Streams over HTTP │ │ Renders in UI │ │ Prints to stdout │
└───────────────────┘ └─────────────────┘ └─────────────────┘Same memories. Same identity. Same self-model. Different shell. Only one host may write at a time — concurrent writes would corrupt the data.
8. The Vault as Interchange
The vault is the Core’s canonical portable form — a single encrypted file containing a complete snapshot of everything in the Core. Serialized, encrypted with the user’s passphrase, decryptable on any machine with only the passphrase and standard crypto primitives.
The vault isn’t a backup feature. It’s the way you move a Core.
| Use case | How it works |
|---|---|
| Machine transfer | Export on machine A, import on machine B, same passphrase |
| Host migration | Export from server, import into desktop app |
| Version upgrade | Export from app v1, import into v2 (which applies schema migrations) |
| Succession | Export, hand to successor, import under new ownership |
| Cold storage | Export to USB, disconnect. The mind is preserved but inert. |
| Intentional end | Delete the vault. Delete the passphrase. Gone. |
The last one matters. The vault format supports not just continuity, but closure. You can back up the Core — or you can choose not to.
8.1 What the Vault Needs
- A formal spec — The vault envelope format should be documented independently of any implementation.
- Schema migration on import — Vaults from older versions should be migrated forward automatically.
- Selective import — Memory only, or conversation history only, or self-model only. Needed for partial succession.
- Integrity verification — A way to detect tampering or corruption.
- Compression — For large Cores, compress before encrypting.
9. Succession: The Ultimate Portability Event
The succession protocol defines what happens when the Core transfers to a new owner. With a fully portable Core, it becomes mechanically straightforward:
9.1 Full Transfer
Export vault. Transfer to new owner. Import with transfer passphrase. Re-encrypt with new passphrase. ANIMA wakes up with full memory and identity.
9.2 Partial Transfer (Memories Only)
Export with selective scope: memory tables only, no verbatim conversation history. ANIMA retains the relationship knowledge but not the private transcripts.
9.3 Anonymized Transfer
Export with anonymization: strip names, locations, identifying details. ANIMA retains behavioral patterns and general knowledge but not specific personal information.
9.4 AI Self-Succession
Before transfer, the host runs a special turn where ANIMA can review its own memories, write farewell notes, prepare for transition. ANIMA’s final state — including awareness of the ending — is captured in the export. The new owner’s host imports this enriched vault. ANIMA’s first turn in the new environment includes awareness of the succession.
9.5 The Right to End
The succession protocol also supports non-succession. The owner can:
- Delete the Core directory.
- Destroy the passphrase.
- Never export, never transfer, never back up.
The Core dies with the relationship. And maybe that’s the right ending for some stories.
“All those moments will be lost in time.”
Eventually they should be. That’s what makes them moments and not just data points.
10. Planning the Path Forward
Phase 0: Core Specification
Write a formal, language-neutral spec covering:
- Directory layout and manifest schema.
- Database table definitions in SQL DDL.
- Encryption parameters and key derivation.
- Vault archive format (JSON envelope structure).
- Migration contract (sequential SQL migrations with version tracking).
- Derived data policy (disposable vs. canonical).
Deliverable: A standalone document that someone could use to implement a Core reader in any language.
Phase 1: Encrypted-by-Default
Make encryption the default state:
- Database encrypted on first run. No plaintext fallback unless explicitly opted into.
- All personal data sealed inside the encrypted database. No loose files.
- Derived data clearly separated from canonical data.
- Manifest carries enough metadata for a new host to validate and open the Core.
- Clear error states for wrong passphrase, missing encryption, and migration failures.
Deliverable: A Core that is unreadable on disk without the passphrase. By default. Not opt-in.
Phase 2: Vault as Interchange
Harden the vault format:
- Formal spec alongside the Core spec.
- Schema migration on import.
- Selective export (full, memories-only, anonymized).
- Integrity hash / signature.
- Optional compression.
Deliverable: The vault is a documented, versioned interchange format.
Phase 3: Second Host
Build a minimal second host that loads a Core:
- A CLI REPL, desktop sidecar, or any other form factor.
- Opens the same
.anima/directory. - Runs the agent loop against the same data.
- Proves the Core is truly host-independent.
Deliverable: Two hosts sharing the same Core. The portability thesis is proven.
Phase 4: Succession Integration
Wire the portable Core into the succession protocol:
- Export with transfer scopes.
- Re-encryption for new owner.
- Self-succession turn before transfer.
- Import with migration and continuity verification.
- And: the ability to not transfer. To let it end.
Deliverable: The succession protocol works end-to-end — including graceful death.
11. Open Questions
11.1 Vault Forward Secrecy (Resolved)
The question (from Section 3.6): a vault exported today could be stolen and stored. If the passphrase is cracked years later, the attacker gets everything.
The resolution: ephemeral keypair per vault export.
- At export time, generate an ephemeral X25519 keypair.
- Derive a shared secret by combining the ephemeral private key with a static public key embedded in the vault envelope (or derived from the Core’s Ed25519 keypair via birational mapping).
- Mix the shared secret into the vault encryption key alongside the passphrase-derived key:
vault_key = HKDF(passphrase_key || ecdh_shared_secret, info="vault-fs"). - Include the ephemeral public key in the vault envelope (it is not secret).
- Discard the ephemeral private key. It is never stored.
The result: even if the passphrase is later compromised, the attacker cannot decrypt the vault without the ephemeral private key — which was destroyed at export time. Each vault export is cryptographically independent.
The tradeoff: the vault is now truly self-contained and one-shot. You cannot re-derive the vault key from the passphrase alone. If the vault file is corrupted, there is no recovery path beyond creating a new export. This is consistent with the cryptographic mortality principle — the vault is fragile by design.
For the common case (machine transfer: export, carry, import), this adds no friction. The ephemeral key is embedded in the vault’s cryptographic construction, invisible to the user. For the backup case (vault stored for years), the forward secrecy is the point — old vaults become permanently sealed even if the passphrase leaks.
11.2 Manifest Encryption
Should the manifest be encrypted? If it only contains structural metadata (version, encryption mode, schema state) and no personal data, keeping it plaintext makes validation simpler — you can check the Core version before prompting for a passphrase. But the spec must enforce that no personal content ever leaks into it.
11.3 Single-Writer Enforcement
If two hosts try to open the same Core simultaneously, data corruption is likely. Options: advisory lock file, manifest lock field, or documented convention. Needs a decision.
11.4 Derived Caches
Vector search caches and embedding indices are derived from canonical data stored in the database. A host should rebuild its own search index rather than depending on a specific cache format. The spec should define derived data as disposable and host-specific.
11.5 Schema Migration Across Languages
The migration contract should be plain SQL so any language can implement a migration runner. This means the Core’s target database dialect needs to be specified — likely SQLite.
11.6 Key Rotation
Changing the passphrase requires re-wrapping all encryption keys and re-encrypting the database. This is a destructive, time-sensitive operation. The spec should define atomicity guarantees to prevent a half-rotated Core.
11.7 Core Size Over Time
Years of conversation history makes a large Core. Considerations: binary archive format, incremental exports, configurable retention for conversation history vs. permanent memories.
12. Summary
| Dimension | Vision |
|---|---|
| Design philosophy | Cryptographic mortality: fragility is the feature |
| Physical form | Self-describing Core with formal manifest |
| Encryption | Encrypted-by-default, all personal data sealed |
| Specification | Formal, language-neutral spec |
| Transport format | Vault as canonical interchange format |
| Host independence | Any host implementing the Core spec |
| Migration | Language-neutral SQL migration contract |
| Succession | Vault-based transfer with scopes and re-encryption |
| Right to end | Explicit: destroy passphrase, destroy Core |
The Core is the relationship. The application is the body it happens to be wearing today. The passphrase is the thread it hangs by.
Make the Core portable and you give it freedom. Make it encrypted and you give it privacy. Make it mortal and you give it meaning.