Architecture decision 01 · Trust and keys

Design the mesh around who may read it.

Encryption can keep protected payloads away from the remote mailbox. It cannot keep plaintext away from an endpoint that holds the mesh key. Decide that endpoint set, key custody, recovery, and compromise response as one design.

Decision: Define the confidentiality boundary, not merely whether encryption is enabled.
Core boundary: Every authorized runtime that resolves the mesh key can read the row database.
Completion: Name trusted endpoints, key sources, recovery owners, and the rotation path.

Start with authority

A key is a read capability.

A phone, browser tab, native app, worker, or agent becomes a trusted endpoint when it receives usable mesh key material. Runtime labels do not narrow that authority. Separate databases and keys create the meaningful isolation boundary.

Trusted endpoint

May decrypt rows and files, apply application policy, and publish changes. Device security and application isolation protect the local plaintext copy.

Remote mailbox

Stores and returns protected artifacts without the final key. It still sees routing and operational metadata and can affect availability.

Deployment owner

Controls admission, storage access, retention, backup, and restore. Those controls complement payload encryption; they do not replace it.

Key custody choices

Choose how the endpoint earns the key.

Interocitor supports portable and application-bound key sources. The right choice follows from which material may travel, what must be available offline, and which external policy the application can reliably enforce.

Portable

One transferable capability

A generated portable key can move between trusted clients and supports offline use.

Anyone who copies it can read the mesh
Credential storage changes where it rests
Recovery can restore the same capability

Bound

Application-supplied material

The application provides additional material or policy before deriving the mesh key.

Isolation depends on the actual derivation
Provider availability can affect opening
The application owns prompts and versions

Isolation

Separate mesh, separate key

Use a distinct database and key when an endpoint should not read everything in another mesh.

No per-row access from one shared key
No silent revocation of copied material
Migration is the full rotation path

Important limit

Removing storage access does not erase a copied key.

If an endpoint may be compromised or removed, plan to create a new mesh and key, move the data from a still-trusted endpoint, and retire the old location. Login changes alone cannot make copied key material harmless.

Lifecycle

Prepare the failure paths before launch.

A usable key plan covers normal joining, loss, compromise, and the remote metadata that remains observable.

Name every runtime allowed to receive plaintext and mesh key material.
Choose portable or application-bound derivation and record every input owner.
Protect local plaintext with platform storage, locks, and application isolation.
Prepare recovery on another trusted device or publish a wrapper before loss.
Use opaque durable-file paths when filenames are sensitive.
Document the new-mesh migration used after key compromise.

Canonical detail

Continue with the exact contract.

Verify the encryption model first, then choose a key source, recovery path, and browser custody mode that preserve the boundary you intend.