The current privacy claim is "your wiki is private by default" — but the operator (us) can still read the data at rest on EFS. For a product whose pitch is "memory for your agents," the data is inherently sensitive: it's the user's working notes, research, plans, and whatever their agents are writing on their behalf.
+
+
Ideally, wiki content would be encrypted client-side so that even the platform operator cannot read it. This is a hard problem for a wiki with a web UI and MCP access — both need to decrypt content to render/search it — but worth investigating.
+
+
**Areas to explore:**
+
- Client-side encryption with key derived from user credential (e.g. HKDF from OAuth token or user-supplied passphrase)
+
- Impact on web UI rendering (decrypt in browser via Web Crypto API?)
+
- Impact on MCP access (agent would need the key — how does that work?)
+
- Impact on semantic search (can't embed encrypted text — is search a premium-only feature anyway?)
+
- Impact on git clone (encrypted blobs in repo, decrypt locally?)
+
- Precedents: Standard Notes, Proton Drive, age-encrypted git repos
+
- Partial approaches: encrypt at rest with per-user KMS keys (operator can't casually surveil, but AWS access would still allow it)
+
+
**Deliverables:**
+
- Design spike: what's feasible, what's the UX impact, what are the tradeoffs
+
- Recommendation: full zero-knowledge, per-user KMS, or "encrypt at rest and be honest about the limits"
+
+
**Acceptance criteria:**
+
- [ ] At least three approaches evaluated with pros/cons
+
- [ ] UX impact documented for web UI, MCP, git clone, and search