papers/lux-threshold-ux/sections/05-shared-workspaces.tex

%% ===================================================================
%% LP-134 canonical naming (2025-12-15):
%% Per LP-134 (Lux Chain Topology), T-Chain has been split into:
%%   M-Chain — MPC ceremonies for bridge custody of EXTERNAL wallets
%%             (CGGMP21, FROST, Pulsar-general)
%%   F-Chain — FHE compute + TFHE bootstrap-key generation (encrypted EVM)
%% The legacy name "T-Chain" is retained ONLY for `teleportvm` (LP-6332).
%% Where this paper says "T-Chain MPC" / "T-Chain threshold governance" /
%% "T-Chain TFHE" / "T-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
%% ===================================================================

\section{Shared Workspaces}
\label{sec:workspaces}

A shared workspace is a capsule whose access control policy grants
multiple users read, write, or admin permissions. The threshold
primitive enables fine-grained collaborative access without a
central server that holds all keys.

\subsection{Access Control via Threshold Decryption}

Workspace data is encrypted under a workspace key $k_W$. The key is
not held by any single user. Instead, it is distributed as a $(t, n)$
threshold key among workspace members:

\begin{definition}[Workspace Threshold Access]
A workspace $W$ with members $\{M_1, \ldots, M_n\}$ and access threshold
$t$ encrypts data under key $k_W$ where $k_W$ is a threshold key requiring
$t$ member key shares for decryption. Different access levels map to
different thresholds:
\begin{itemize}
    \item \textbf{Read}: $t_{\text{read}} = 1$ (any member can read)
    \item \textbf{Write}: $t_{\text{write}} = 1$ (any member can write, with CRDT merge for conflicts)
    \item \textbf{Admin}: $t_{\text{admin}} = \lceil n/2 \rceil + 1$ (majority required for policy changes)
\end{itemize}
\end{definition}

For the common case of $t_{\text{read}} = 1$, each member holds a copy of
the workspace key encrypted under their personal key. This avoids the
latency of threshold decryption for reads while preserving threshold
control for administrative actions.

\subsection{Collaborative Editing with CRDTs}

Workspace documents use Conflict-free Replicated Data Types (CRDTs)
\cite{shapiro2011crdt} for concurrent editing. Each member edits their
local encrypted copy, generating CRDT operations that are encrypted and
broadcast to other members via relay providers. Merging happens locally
on each member's device:

\begin{equation}
    \mathsf{Doc}_{M_i} = \mathsf{Merge}(\mathsf{Doc}_{M_i}, \mathsf{Decrypt}(k_W, \mathsf{ops}_{M_j}))
\end{equation}

No server sees plaintext. The CRDT guarantees eventual consistency:
all members converge to the same document state regardless of the
order in which operations are applied.

\subsection{Member Management}

Adding or removing workspace members requires threshold admin approval:

\begin{enumerate}
    \item A member proposes adding/removing a user.
    \item The proposal is submitted as a T-Chain threshold approval flow
    with $t_{\text{admin}}$ threshold.
    \item When approved, the workspace key is re-shared to include/exclude
    the affected member.
    \item For member removal, the workspace key is rotated (generating a
    fresh key and re-encrypting all data) to ensure the removed member
    cannot decrypt future updates.
\end{enumerate}

\begin{proposition}[Forward Secrecy on Member Removal]
After a member $M_r$ is removed and the workspace key is rotated, $M_r$
cannot decrypt any data written after the rotation epoch, even if $M_r$
retains their old key share. This follows from the key independence
property: the new workspace key $k_W'$ is generated independently of
$k_W$ and is never encrypted under $M_r$'s personal key.
\end{proposition}