Files
zeekay abf99d05fc papers: reorganize into per-paper dirs, add Antje Worring as co-author
Restructured from flat .tex/.pdf files into per-paper subdirectories.
Added Antje Worring as co-author on all papers.
Synced PDFs to pdfs/ for download site.
2026-04-18 21:50:07 -07:00

50 lines
2.1 KiB
TeX

\section{Migration Path}
\label{sec:migration}
% ============================================================================
Existing applications built on Firebase, Supabase, Notion APIs, or similar
centralized backends can migrate to capsule-based architectures incrementally.
\subsection{Migration Mapping}
\begin{table}[H]
\centering
\caption{Migration from centralized backends to capsule architecture.}
\label{tab:migration}
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Centralized} & \textbf{Capsule Equivalent} & \textbf{Trust Model} \\
\midrule
Firebase Auth & I-Chain DID + session tokens & Self-sovereign \\
Firestore & Encrypted SQLite vault & Local-first \\
Realtime DB & CRDT sync over $\Sigma$ & Peer-to-peer \\
Cloud Storage & Encrypted blob at provider & Provider-blind \\
Cloud Functions & Base plugins (WASM/V8) & Sandboxed \\
Security Rules & $\Gamma$ capability lattice & Cryptographic \\
Push notifications & Sync event subscriptions & Local observer \\
Analytics & Aggregation via Class III FHE & Confidential \\
\bottomrule
\end{tabular}
\end{table}
\subsection{Migration Strategy}
\begin{enumerate}[nosep]
\item \textbf{Phase 1: Dual-write.} The application writes to both the
existing backend and a local capsule vault. Reads come from the
centralized backend. This validates data model compatibility.
\item \textbf{Phase 2: Local-read.} Reads switch to the local vault.
The centralized backend becomes a sync target (write-through).
The user experiences offline capability and reduced latency.
\item \textbf{Phase 3: Cut-over.} The centralized backend is removed from
$\Sigma$. The capsule's CRDT sync handles replication. Identity
migrates to I-Chain. The old backend is decommissioned.
\end{enumerate}
The key constraint: the application's data model must fit SQLite's relational
schema. Document databases (Firestore, MongoDB) require schema normalization.
Key-value stores map directly. Graph data requires an adjacency-list
representation or a dedicated CRDT type.
% ============================================================================