mirror of
https://github.com/hanzoai/papers.git
synced 2026-10-29 07:34:31 +00:00
55 lines
2.7 KiB
TeX
55 lines
2.7 KiB
TeX
\section{Introduction}
|
|
|
|
\label{sec:intro}
|
|
% ============================================================================
|
|
|
|
Software is not sovereign. The applications people depend on daily---messaging,
|
|
notes, banking, health records---exist as tenants on infrastructure controlled
|
|
by third parties. The user's data lives in a provider's database, encrypted
|
|
with the provider's keys, governed by the provider's terms. If the provider
|
|
disappears, so does the application. If the provider changes policy, the user
|
|
complies or loses access. This is not ownership. It is tenancy.
|
|
|
|
The problem is architectural. Cloud-native design treats the network as a given:
|
|
every read is a round-trip, every write is a permission request, every query is
|
|
metered. The application is a thin client to someone else's computer. The
|
|
alternative---self-hosting---requires expertise that excludes all but a small
|
|
technical minority. There is no middle ground.
|
|
|
|
Base is the middle ground.
|
|
|
|
\begin{definition}[Sovereign Application]
|
|
An application is sovereign if: (i) the user controls the encryption keys for
|
|
all stored data, (ii) the application functions without any network connection,
|
|
(iii) replication to any remote host is opt-in and reversible, and (iv) no
|
|
third party can unilaterally revoke access to the application or its data.
|
|
\end{definition}
|
|
|
|
Base achieves sovereignty by inverting the cloud model. Instead of a thin
|
|
client talking to a remote server, Base is the server---running locally, owning
|
|
its own database, generating its own keys. Remote services (cloud storage, chain
|
|
anchoring, peer sync) are optional extensions, never requirements.
|
|
|
|
\subsection{Contributions}
|
|
|
|
\begin{enumerate}[leftmargin=1.4em]
|
|
\item A single-binary application runtime with embedded encrypted database,
|
|
realtime APIs, authentication, and plugin system
|
|
(\S\ref{sec:architecture}).
|
|
\item A data plane architecture where local storage is primary and remote
|
|
replication is provider-optional (\S\ref{sec:dataplane}).
|
|
\item Base Functions: TypeScript execution in an embedded Goja VM with
|
|
zero cold start and event-driven hooks (\S\ref{sec:functions}).
|
|
\item Base Collections: schemaless records with row-level access rules and
|
|
field-level KMS encryption (\S\ref{sec:collections}).
|
|
\item Base Sync: CRDT-based conflict-free replication supporting
|
|
offline-first, peer-to-peer, and server-relay topologies
|
|
(\S\ref{sec:sync}).
|
|
\item Integration with Lux Network for key policy, identity, and threshold
|
|
controls (\S\ref{sec:lux}).
|
|
\item Performance evaluation showing 10,400 encrypted writes/sec and
|
|
sub-millisecond reads on commodity hardware (\S\ref{sec:performance}).
|
|
\end{enumerate}
|
|
|
|
% ============================================================================
|