papers/lux-capsule-architecture/sections/10-hardest-unsolved-problems.tex

\section{Hardest Unsolved Problems}
\label{sec:unsolved}
% ============================================================================

Honesty demands listing what we have not solved. These are open research
problems, not engineering tasks.

\subsection{Key Rotation UX}

Rotating a capsule's root key requires re-wrapping $k_{\mathsf{enc}}$ and
updating the DID document. For a single-device user, this is straightforward.
For a user with 10 devices, 5 shared workspaces, and 3 agent capsules, key
rotation becomes a coordination problem. Every derived key must be re-derived.
Every peer in $\Sigma$ must receive the new sync key. Every agent's delegated
capabilities must be re-issued.

The current protocol handles this through a rotation transaction on K-Chain that
emits a rotation event, triggering re-keying across all derived capsules. The
UX problem: if any device is offline during rotation, it holds stale keys
and cannot sync until it comes online and processes the rotation event. We do
not have a satisfying solution for the offline-device-during-rotation case
beyond ``queue the rotation and apply on reconnect,'' which creates a window
where the old key is still valid.

\subsection{Partial Sharing}

A principal wants to share rows 1--50 of a table but not rows 51--100. The
current capability model operates at table granularity. Row-level sharing
requires either: (a) splitting the table into separate vaults (one shared,
one private), which fragments the schema; or (b) implementing row-level
encryption with per-row keys, which multiplies key management complexity.

Neither approach is clean. The fundamental tension: SQLite operates on pages,
not rows. Encrypting at row granularity means abandoning SQLCipher's
page-level encryption for a custom scheme with worse performance
characteristics.

\subsection{Sync Metadata Leakage}

Even with encrypted payloads, the sync protocol leaks metadata: which capsules
sync with which peers, how often, and how much data flows. A traffic analysis
adversary can infer social graphs and activity patterns from sync metadata
alone.

Mitigations include constant-rate padding (expensive), mix networks for relay
traffic (high latency), and PIR for checkpoint retrieval (computationally
expensive). None are satisfactory for real-time sync workloads.

\subsection{Private Search and Indexing}

Searching encrypted vault data is an open problem. Searchable symmetric
encryption (SSE) leaks access patterns. Oblivious RAM (ORAM) has
$O(\log n)$ overhead per access. FHE-based search is orders of magnitude
slower than plaintext search.

For Class I applications, search is local and fast (plaintext after
decryption). The problem arises for Class II and III applications where a
provider must search on behalf of a principal without seeing plaintext.
Practical private search at scale remains unsolved.

\subsection{Agent Memory Permissions}

An agent's vault accumulates memory over time: conversation history, learned
preferences, tool outputs. The principal who spawned the agent should be able
to: (a) read all agent memory, (b) selectively delete memories, (c) prevent
the agent from remembering certain interactions.

The challenge: if the agent has write access to its own vault (necessary for
it to function), it can write anything, including data the principal wishes
it would not retain. Enforcing ``do not remember this'' requires either
trusted hardware (TEE for the agent runtime) or a formal verification
framework for agent write policies. Neither is production-ready.

\subsection{Cross-Application Composition}

A user wants Application A's data to feed into Application B's computation.
Both applications use separate capsules. The composition requires: (a) a
capability delegation from Capsule A to Capsule B, (b) a data format
agreement, and (c) a sync path between the two vaults.

The protocol supports this mechanically (delegate a read capability, establish
a sync link), but the UX is unresolved. Users should not need to understand
capability lattices and CRDT topologies to connect two apps. The equivalent
of ``Sign in with Google'' for cross-app data sharing in Web5 does not
exist yet.

% ============================================================================