Blog
Private memory infrastructure
Why the memory problem is an infrastructure problem, and what follows if you refuse to solve it with engagement. A plain reading of Confinity's architecture.By Confinity · February 10, 2026 · 3-minute readQuiet tools, not a toolbar.
Memory isn't content
Four infrastructure decisions, made out loud
- Storage is addressable, not opaque. Everything inside Confinity has a durable identifier that survives a migration. When we move a user from one region to another, or one storage tier to another, links inside the journal stay valid. If we ever went out of business, an export would be navigable by a stranger with a text editor. Durability means "can be read without us being alive to help you."
- Encryption is envelope-based, not marketing-based. We do not claim "end-to-end" because that claim leaks: recovery flows, family sharing, and moderation all require servers that read. What we do do is encrypt data at rest with per-user keys, separate key custody from data custody, and publish our exact posture in the Trust Centre. Being honest about what "private" means is more protective than being aspirational.
- Succession is first-class. Every account has a successor contract — who inherits it, on what trigger, with what permissions. It is boring, it is not a feature you open an app to use, and it is the single thing that separates memory infrastructure from a photo app. If Confinity goes away, succession is what keeps the work doing its job.
- Portability is unconditional. Export is free, complete, and machine-readable. No "download a preview, pay for the rest." No lock-in by schema obscurity. The implicit pact is that you could leave us tomorrow and lose nothing structural. That pact is what earns us the right to be the archive.