Encryption at rest for private stores (and optional sealed mailboxes) #11

Goal

Encrypt sensitive 3Notch material at rest so shared disks, sync folders, and backups are not plain-text trust-the-filesystem.

Why now

Local-first does not mean forever plaintext. Multi-machine and teammate workflows need a stronger story than OS disk encryption alone. README already lists encryption at rest for .notch/private/ under hardening.

Proposed phasing

Phase A — private store (default first target)

• Encrypt contents under .notch/private/ (seeds, private marks/outbox as applicable).
• Key management that stays user-controlled (no hosted KMS required): passphrase, OS keychain, or file-based key with clear threat model.
• Agents/MCP only see plaintext when the store is unlocked for that process (design this carefully with --include-private).

Phase B — optional sealed mailbox deliveries

• Optional encryption of durable-inbox archives so a shared/synced mailbox root is not readable by every process with path access.
• Keep private/seed blocked from the shared-mailbox flow unless explicitly sealed + policy allows (do not casually reopen that door).

Non-goals

• Hosted account or cloud key custody.
• DRM or hiding content from the user who owns the keys.
• Claiming encryption replaces sender authentication (see authorship/signing issue).

Design questions to settle before build

• Format (age, libsodium sealed box, age+SSH, etc.) and what is encrypted vs hashed in clear metadata.
• Unlock UX for CLI vs long-running MCP.
• Migration for existing plaintext private trees.
• How audit logs refer to encrypted objects without leaking content.

Acceptance ideas

• Written threat model + format choice in docs/security story.
• Phase A implemented with tests for lock/unlock, failed unlock, and MCP private visibility rules.
• Migration path documented; doctor/status surface locked vs unlocked state.
• Phase B design note even if implementation follows later.

Related

• Complements multi-machine recipes (docs can warn until this ships).
• Pairs with packet authorship/signing; does not replace it.
• Remote transport should prefer sealed payloads once available.