Every device keeps its own diary — not one shared list of everything you own

Add a second device to almost any sync-enabled app and, somewhere on a server, a master list gets updated: here is everything this account owns, and here is which device just joined. That list is convenient. It is also, on its own, a complete inventory of a person's data — reachable by anyone who can reach the account, whether that is the rightful owner, an attacker, or a legal request. Prevon does not keep one.

The problem with a shared master list

A single, shared index of "everything this vault contains" is a single point of failure in two different senses. Technically, it is one object that, if corrupted or unreachable, can take your entire history down with it. And from a privacy standpoint, it is a complete table of contents handed to whoever can read it — which defeats the point of encrypting the contents in the first place, the same way a locked filing cabinet with a detailed label on every drawer is not really sealed information.

One private, append-only diary per device

Instead, every device you use — your phone, your laptop, an old tablet you barely open anymore — keeps its own private, append-only record of what it created or deleted. Nothing is shared or overwritten between devices, because nothing needs to be. There is no single object anywhere that lists "everything," because that object was never necessary to build the feature in the first place — it was just the easy way to build it, at the cost of being exactly the kind of thing this architecture is designed to avoid.

A system with no master list has no master list to lose, leak, or subpoena.

When you set up a new device, it does not ask a server "what does this person have?" — there is no server that could answer that question even if asked. It reconstructs your history the same way it locates your notes in the first place: by computing, from your Recovery Seed, where its own devices' records live, then merging what it finds. Real-time sync between devices you are actively using works the same way it always has; this is specifically about how a new or returning device catches up without ever depending on a central inventory existing anywhere.

This mirrors how real decentralized systems already work

This is not a novel or unproven idea — it is the same architecture used by mature, real-world decentralized social and messaging protocols, where each participant publishes to their own independent log instead of everyone editing one shared database. It trades a small amount of convenience — reconstructing history takes real computation instead of one simple lookup — for removing an entire category of target: there is no central list of your data for anything or anyone to go after, because it was never built to exist in the first place.