Why we didn't build vault encryption first

The free, local tier has no encryption key, no cryptographic identity, and no account. That's not a corner we cut. It's a deliberate call about what a security layer is actually for.

The question we kept getting

“If my memories are sensitive, why isn't the vault encrypted at rest?” is a fair question, and the honest answer is that on a local-only install, there's no one else in the room for encryption to defend against. The daemon exposes exactly one Unix domain socket, permissioned 0600, and the kernel independently verifies that any connecting process shares the daemon's own OS user before it's allowed to talk to it. The storage files themselves are 0600 too. A process running as a different OS user is refused by the operating system before it ever reaches our code: the same guarantee a crypto handshake would provide, already enforced by something the kernel has been doing for decades.

Where a key would actually go

A same-OS-user process already has direct file access regardless of what a socket requires. Adding a cryptographic handshake on top wouldn't stop anything that permission check doesn't already stop; it would just be a second lock on a door the first lock already fully controls. Cryptographic identity earns its keep the moment two different machines need to trust each other, which is exactly why it shows up in ModelBrain the first time a node subscribes to paid networking: that's the first moment there's a second party for a key to authenticate against.

The one place a key already exists today

Managed backup is the exception, and it's encrypted client-side before it ever leaves your machine, so we hold a copy we can't read. That's a genuinely different situation from the local daemon: the ciphertext is headed somewhere we don't control, so a key is the only thing standing between us and your data, and there the key exists from day one.