mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
f4ee7a0525
Bylines, paper authorship, correspondence addresses and the founder blurb under each post named an individual. They name the organisation that published the work instead: the brand on posts and pages, the research byline on papers, and research@ in place of a personal address. Both are what these repositories already used elsewhere — nothing new was coined. Co-authors are untouched. Where a paper named someone else alongside, they stay named; only the one byline changed. Bibliography entries, running heads, PDF metadata and affiliations move with it, so a citation still resolves to whoever the cited paper names. Sample and fixture data uses the placeholder name these tests already use elsewhere, so no assertion changed meaning.
105 lines
4.5 KiB
TeX
105 lines
4.5 KiB
TeX
\documentclass[twocolumn,11pt]{article}
|
|
\usepackage{shared/luxcover}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage{amsmath,amssymb}
|
|
\usepackage{graphicx}
|
|
\usepackage{hyperref}
|
|
\usepackage{booktabs}
|
|
\usepackage[numbers]{natbib}
|
|
\usepackage{abstract}
|
|
|
|
\title{\textbf{Private Apps on Web5: Local-First Decentralized Cloud Applications}}
|
|
|
|
\author{
|
|
Lux Research\thanks{[email protected]}\\
|
|
\textit{Lux Industries \quad Hanzo AI \quad Zoo Labs Foundation}\\
|
|
\texttt{[email protected]}
|
|
}
|
|
|
|
\date{April 2025}
|
|
|
|
\begin{document}
|
|
\luxcoverpage
|
|
|
|
\begin{abstract}
|
|
Web5 is a local-first application architecture where mutable state lives in encrypted per-user SQLite vaults, synchronized via CRDTs, and anchored to a blockchain trust layer for identity, key policy, capability grants, and audit receipts. This paper defines the architecture, explains why blockchains are excellent trust planes but poor data planes, and describes the concrete implementation using Lux Network VMs and Hanzo Base.
|
|
\end{abstract}
|
|
|
|
\section{Thesis}
|
|
|
|
\textit{Put trust on-chain, keep state local, sync privately, make identity portable.}
|
|
|
|
Web5 is not ``apps fully on-chain.'' Web5 is local-first apps with a shared cryptographic trust layer that gives users ownership and speed, developers a better runtime, and operators a new model for decentralized cloud.
|
|
|
|
\section{The Web5 Stack}
|
|
|
|
\begin{center}
|
|
\begin{tabular}{lll}
|
|
\toprule
|
|
\textbf{Layer} & \textbf{Role} & \textbf{Stores} \\
|
|
\midrule
|
|
Client vault & Data plane & Encrypted SQLite, CRDT log \\
|
|
Sync layer & Replication & Ciphertext ops, snapshots \\
|
|
Trust layer & Control plane & DIDs, keys, policies, anchors \\
|
|
Provider layer & Utility market & Relays, storage, signers \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\section{Why SQLite + CRDT}
|
|
|
|
SQLite is an ideal unit of tenancy: durable, compact, cross-platform, single-writer per file~\cite{sqlite2020}. CRDTs solve merge after independent edits~\cite{shapiro2011}. Together they give a clean runtime for mobile, desktop, browser, and edge.
|
|
|
|
The practical unit: one vault per user, one per organization, one per shared workspace. Horizontal scale comes from sharding by principal, not concentrating into one shared database.
|
|
|
|
\section{Where Blockchain Belongs}
|
|
|
|
On-chain: identity roots, key handles, wrapping policy, rotation history, capability grants, revocations, sync checkpoint anchors, provider discovery, payments, governance.
|
|
|
|
Not on-chain: application documents, messages, notes, settings, collaborative edits.
|
|
|
|
\section{Security Model}
|
|
|
|
ML-KEM establishes shared secrets for key wrapping (NIST FIPS 203~\cite{nist-mlkem}). Symmetric encryption (AES-256-GCM) protects vault data. Threshold policies handle recovery and delegation. Chain receipts provide verifiable policy state.
|
|
|
|
\section{Product Architecture}
|
|
|
|
\textbf{Hanzo Base} becomes the Web5 app runtime (data plane). \textbf{Lux} becomes the trust and coordination layer (control plane). The synthesis: one encrypted CRDT-backed SQLite vault per principal, decrypted locally, synced as ciphertext, anchored to Lux.
|
|
|
|
\section{Firebase Replacement}
|
|
|
|
\begin{center}
|
|
\begin{tabular}{ll}
|
|
\toprule
|
|
\textbf{Firebase} & \textbf{Web5} \\
|
|
\midrule
|
|
Auth & DID + capability/session gateway \\
|
|
Firestore & Encrypted SQLite shard \\
|
|
Offline sync & CRDT (local-first by default) \\
|
|
Storage & Encrypted blob providers \\
|
|
Functions & Workers on sync/anchor events \\
|
|
Security Rules & Capability grants + chain policy \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
Migration: keep the app, change the backend shape.
|
|
|
|
\section{Decentralized Cloud}
|
|
|
|
Cloud providers become optional and replaceable. Users own keys. Providers rent sync, storage, indexing, signing, and recovery. The protocol is small enough that many operators can implement it, strong enough that apps can rely on it for portability and trust.
|
|
|
|
\section{Conclusion}
|
|
|
|
Each user, org, or app gets its own encrypted CRDT-backed SQLite vault. Vaults execute locally, sync as ciphertext, and anchor trust to Lux. Providers relay, store, recover, and index without owning the data. That is the decentralized cloud model.
|
|
|
|
\bibliographystyle{plainnat}
|
|
\begin{thebibliography}{9}
|
|
\bibitem{sqlite2020} R. Hipp, ``SQLite: Past, Present, and Future,'' \textit{Proc. VLDB Endow.}, 2022.
|
|
\bibitem{nist-mlkem} NIST, ``Module-Lattice-Based Key-Encapsulation Mechanism Standard,'' FIPS 203, 2024.
|
|
\bibitem{shapiro2011} M. Shapiro et al., ``Conflict-Free Replicated Data Types,'' \textit{SSS 2011}, LNCS 6976.
|
|
\bibitem{kleppmann2019} M. Kleppmann et al., ``Local-First Software,'' \textit{Onward! 2019}.
|
|
\end{thebibliography}
|
|
|
|
\end{document}
|