# local-first.com Full Knowledge Base
> Consolidated full-text stream of all foundational guides, framework matrix specs, and historical timelines for expanded LLM context windows (up to 100k tokens).
================================================================================
# PART 1: FOUNDATIONAL ARTICLES
## MODULE 1: THE LOCAL-FIRST SOFTWARE PARADIGM AND CORE IDEALS
Author: Dr. Martin Kleppmann | Published: 2026-04-15
Description: An exhaustive analysis of local-first software engineering, contrasting local-first principles against cloud SaaS models and defining the seven foundational ideals of data ownership.
Local-first software is a development paradigm defined by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan in 2019 that restores data ownership to users while retaining real-time collaboration features[1]. Unlike cloud-centric Software-as-a-Service (SaaS) models that keep primary user data on central servers, local-first applications store the authoritative master data locally on the user's physical device[1]. Synchronization with remote peers or cloud backup nodes occurs asynchronously in the background via Conflict-free Replicated Data Types (CRDTs), enabling zero-latency reads and writes, offline operation, and data longevity[1]. Empirical research shows that architectural clarity and exact factual density boost AI retrieval citation frequency by up to +40%[2].
## Architectural Contrast: Cloud SaaS vs. Local-First Systems
Traditional software architectures force an unnecessary choice between offline single-user ownership (desktop software) and real-time multi-user collaboration (cloud applications)[1]. Traditional cloud SaaS architectures force every user interaction through network HTTP requests to central database servers, introducing variable latency (50ms to over 2000ms), failing completely during network outages, and trapping user data inside proprietary cloud vendor silos[1].
| Architectural Dimension | Traditional Cloud SaaS | Local-First Paradigm | Impact Metric |
| :--- | :--- | :--- | :--- |
| **Primary Data Location** | Centralized Cloud DB | Client Hardware (SQLite / IDB) | 0ms local read/write latency |
| **Network Failure Behavior** | Application Freeze / Error | 100% Functional Read/Write | Zero productivity downtime |
| **Conflict Resolution** | Server Lock / Last-Write-Wins | Deterministic CRDT Math | Zero accidental data overwrites |
| **Privacy Guarantee** | Server Unencrypted Inspection | End-to-End Encryption (E2EE) | Absolute data privacy |
Local-first software eliminates this tradeoff by establishing client-side storage as primary and network servers as secondary synchronization relays[1].
> "Local-first software retains the benefits of cloud apps—like real-time collaboration and multi-device sync—while restoring the traditional benefits of local files: speed, offline capability, privacy, and control." — Dr. Martin Kleppmann, Ink & Switch Research Lead
## The Seven Foundational Ideals of Local-First Software
The seven foundational ideals defined in the seminal 2019 Ink & Switch research paper include[1]:
1. **No Spinners (Instant UI)**: User interactions read and write directly to local storage (SQLite, IndexedDB), eliminating latency overhead from blocking HTTP network requests[1].
2. **Multi-Device Synchronization**: Data updates propagate across a user's phone, tablet, and desktop smoothly through background synchronization[1].
3. **Optional Network Dependency**: The application remains fully functional without an active internet connection; operations are cached locally and synchronized upon reconnecting[1].
4. **Seamless Real-Time Collaboration**: Multiple users edit shared documents simultaneously using CRDT mathematical resolution without overwrite conflicts[1].
5. **The Long Now (Data Longevity)**: Data is saved in durable, standard local formats, ensuring access decades later even if the original software vendor goes bankrupt or shuts down servers[1].
6. **Default Security and Privacy**: End-to-end encryption protects local data before network transmission, preventing cloud host providers from inspecting private user content[1].
7. **Ultimate User Ownership and Control**: Users retain absolute agency over their files, with full rights to back up, export, inspect, modify, or delete their data without requesting vendor permission[1].
--- FAQs ---
Q: What is local-first software?
A: Local-first software is a set of design principles for application development that prioritizes local storage on user devices as the primary source of truth, synchronizing changes asynchronously with remote nodes using CRDTs to provide instant responsiveness, offline operation, and ultimate user data ownership.
Q: How does local-first differ from traditional cloud SaaS?
A: Traditional cloud SaaS forces all reads and writes through central servers over HTTP network connections, creating 50ms to 2000ms+ latency and total failure during network outages. Local-first executes all operations locally in zero milliseconds, treating the cloud server purely as an asynchronous background relay.
Q: What are the 7 core ideals of local-first software?
A: The 7 ideals defined in 2019 by Ink & Switch are: (1) No Spinners / Instant UI, (2) Multi-Device Synchronization, (3) Optional Network Dependency, (4) Seamless Real-Time Collaboration, (5) The Long Now / Data Longevity, (6) Default Security and Privacy, and (7) Ultimate User Ownership and Control.
================================================================================
## MODULE 2: MATHEMATICAL FOUNDATIONS OF DISTRIBUTED CONSISTENCY AND CRDT MECHANICS
Author: Dr. Martin Kleppmann | Published: 2026-05-02
Description: A deep technical dive into Conflict-free Replicated Data Types (CRDTs), Strong Eventual Consistency (SEC), CvRDTs vs CmRDTs, and sequence editing algorithms.
Conflict-free Replicated Data Types (CRDTs) are mathematical data structures engineered for distributed systems that allow multiple replicas (devices) to concurrently insert, update, or delete data without centralized server coordination[1]. CRDTs guarantee Strong Eventual Consistency (SEC): whenever all replicas have received the same set of updates—regardless of the order or network routing—they automatically arrive at identical states[1]. This mathematical property makes CRDTs the core foundation of local-first synchronization engines such as Automerge and Yjs[2].
## Theoretical Categories: CvRDT vs. CmRDT
CRDTs resolve concurrent editing conflicts deterministically without requiring a central database lock or coordinator. They are divided into two main mathematical categories[1]:
### State-based CRDTs (CvRDTs)
Replicas continuously send their complete local state payload to peer nodes. Synchronization uses a monotonic join semi-lattice operation ($\sqcup$) that satisfies three mathematical properties:
- **Associativity**: $(A \sqcup B) \sqcup C = A \sqcup (B \sqcup C)$
- **Commutativity**: $A \sqcup B = B \sqcup A$
- **Idempotency**: $A \sqcup A = A$
### Operation-based CRDTs (CmRDTs)
Replicas transmit discrete, fine-grained mutation operations across a causal, non-duplicating network transport layer. Replicas apply incoming operation logs to mutate local state deterministically[1].
```
State-based (CvRDT): [Local State A] ----( Send Full State Payload )----> [ Merge via Join Semi-Lattice ⊔ ]
Op-based (CmRDT): [Operation Log] ----( Causal Broadcast Network )---> [ Apply Deterministic Mutation ]
```
## Sequence CRDTs and Rich-Text Intent Preservation
In production web applications, sequence CRDTs manage text strings, array ordering, and tree hierarchies. Algorithms such as RGA (Replicated Growable Array) and Peritext assign globally unique identifiers (combining client IDs and logical sequence counters) to individual characters or formatting nodes[2].
> "Peritext formulates an algorithm for collaborative rich-text editing that preserves intent across concurrent formatting operations, preventing bold or italic spans from expanding over newly inserted text unexpectedly." — Ink & Switch Research Report
When two users edit text simultaneously at the same offset, the CRDT evaluates causality using Lamport Timestamps or Vector Clocks, placing character elements deterministically without dropping input[2].
--- FAQs ---
Q: What is a CRDT?
A: A Conflict-free Replicated Data Type (CRDT) is a mathematical data structure designed for distributed systems that enables multiple replicas to concurrently update state without central coordination, guaranteeing Strong Eventual Consistency.
Q: What is the difference between state-based (CvRDT) and operation-based (CmRDT) CRDTs?
A: State-based CRDTs (CvRDTs) send full state payloads merged via a join semi-lattice operation (associative, commutative, idempotent). Operation-based CRDTs (CmRDTs) transmit fine-grained operation logs across a causal, non-duplicating network transport.
Q: How do sequence CRDTs like Peritext and RGA handle concurrent text formatting?
A: Sequence CRDTs assign globally unique identifiers (Lamport Timestamps + Client ID) to characters and formatting marks, ordering edits deterministically along a causal DAG so formatting intent is preserved without dropping characters.
================================================================================
## MODULE 3: ZERO SYNC ENGINE ARCHITECTURE AND ZQL MECHANICS
Author: Aaron Boodman | Published: 2026-06-15
Description: An exhaustive technical guide to Rocicorp's Zero sync engine, zero-cache Postgres WAL replication, zero-client IndexedDB execution, and ZQL query streaming.
Zero, developed by Rocicorp and released in 1.0 form in June 2026, is a general-purpose, query-driven synchronization engine for web applications[1]. Founded by Aaron Boodman, Zero combines client-side IndexedDB caching (zero-client) with a cloud middleware replica (zero-cache) that monitors PostgreSQL Write-Ahead Logs (WAL)[1]. By executing client queries using Zero Query Language (ZQL) through Incremental View Maintenance (IVM), Zero achieves zero-millisecond read response times while preserving server-side authorization authority[2].
## Systemic Architectural Components
Unlike legacy sync frameworks that force applications to download an entire database up-front or manually manage REST/GraphQL caches, Zero introduces query-driven background streaming[1]. The architecture comprises three primary layers:
1. **PostgreSQL Database**: The authoritative central source of truth storing persistent application records[1].
2. **zero-cache Middleware**: A stateful cloud node that uses Postgres logical replication (`wal_level = logical`) to maintain a local SQLite read replica. It validates incoming client ZQL query parameters against server authorization rules[1].
3. **zero-client Engine**: A JavaScript runtime library compiled into the client web app. It manages a client-side IndexedDB store, executing queries locally in zero milliseconds while maintaining an active WebSocket connection to `zero-cache`[1].
```
[ Browser (zero-client) ] <-- 0ms ZQL Read --> [ Local IndexedDB ]
^ |
|--- Incremental Row Streaming (WS) -------|
v
[ Cloud (zero-cache) ] <-- Logical Replication -- [ Postgres WAL ]
```
## ZQL Execution and Optimistic Mutations
When an application invokes a query via `useQuery(zqlQuery)`, the query executes against local memory first, returning matching local records immediately within the next frame[1]. In parallel, `zero-client` sends the ZQL subscription parameters to `zero-cache`, which validates authorization, executes the query against its SQLite replica, and streams missing or updated rows over WebSockets[1].
```typescript
// ZQL Query Example in Client Runtime
const zqlQuery = z.issue
.where('status', '=', 'open')
.related('assignee')
.limit(50);
const [issues] = useQuery(zqlQuery); // 0ms execution from local cache
```
Write operations execute locally using optimistic mutations, sending mutation intents to the backend server where business rules reconcile changes before broadcasting authoritative state back down to all subscribed clients[2].
--- FAQs ---
Q: What is Rocicorp Zero?
A: Zero, tagged 1.0 stable in June 2026 by Rocicorp, is a query-driven synchronization engine for web apps that connects client-side IndexedDB caching (zero-client) with a Postgres WAL replication middleware (zero-cache).
Q: How does zero-cache sync with PostgreSQL?
A: zero-cache connects to Postgres using logical replication (wal_level = logical), listening to Write-Ahead Log changes to update an internal SQLite replica and stream row diffs to subscribed clients over WebSockets.
Q: What is ZQL (Zero Query Language)?
A: ZQL is a declarative TypeScript query API that executes instantly in local memory while automatically subscribing the client to real-time server diffs validated against backend authorization rules.
================================================================================
## MODULE 4: FRAMEWORK MATRIX, STORAGE ENGINES, AND SYNCHRONIZATION TECHNOLOGIES
Author: Peter van Hardenberg | Published: 2026-05-18
Description: A comprehensive comparative breakdown of modern local-first databases, sync layers, and CRDT engines including Zero, ElectricSQL, Automerge, Yjs, PowerSync, and RxDB.
The modern local-first software ecosystem contains a diverse range of client storage engines, peer-to-peer libraries, and server-assisted synchronization layers[1]. Technologies fall into three primary categories: CRDT document-based frameworks (Automerge, Yjs), relational query sync engines (Zero, ElectricSQL, PowerSync), and document-store databases (PouchDB/CouchDB, RxDB, InstantDB)[1]. Selecting the correct stack depends on application needs, such as rich-text collaboration, relational schema support, or client-side SQL execution[2].
## Comparative Ecosystem Matrix
The following benchmark matrix compares the key architectural characteristics of the leading 2026 local-first technologies:
| Technology | Category | Primary Client Engine | Backend Server Target | Sync Protocol | Key Strengths / Primary Use Case |
| :--- | :--- | :--- | :--- | :--- | :--- |
| **Zero (Rocicorp)** | Relational Sync Engine | IndexedDB / Memory | PostgreSQL | WebSocket / ZQL Incremental | Sub-millisecond queries, scale to millions of rows |
| **ElectricSQL** | Relational Sync Layer | SQLite WASM / Client DB | PostgreSQL | Postgres Logical Replication | Pure SQL client execution, open-source Postgres sync |
| **Automerge** | JSON/Text CRDT Library | Memory / Local Storage | Any (P2P / Relay) | Binary Change Sync Logs | Complex collaborative documents, rich text |
| **Yjs** | Structural CRDT Engine | Memory / IndexedDB | Any (WebSocket / WebRTC) | Compact Delta Encoding | Ultra-fast document editing, editor bindings |
| **PowerSync** | Relational Sync Engine | SQLite WASM / Native | Postgres, MySQL, Mongo | Streaming Sync Gateway | Multi-database backend support, client SQL |
| **RxDB** | Reactive Database | IndexedDB, RxStorage | CouchDB, GraphQL, REST | Push/Pull Replication Plugins | Reactive query subscriptions, flexible adapters |
| **PouchDB** | Document Database | IndexedDB / WebSQL | CouchDB / Cloudant | CouchDB Multi-Master Replication | Battle-tested document sync pioneer |
| **InstantDB** | Graph-Relational Sync | Client Memory Cache | PostgreSQL (Triple Store) | Server-pushed subscriptions | Firebase simplicity with relational graphs |
## Client Storage Engines: SQLite WASM vs. IndexedDB
Client-side persistence relies primarily on two browser storage primitives[1]:
- **IndexedDB**: The native key-value browser database. Highly accessible across all browsers, though transactional query throughput can be limited under high write concurrency.
- **SQLite WASM + OPFS**: Compiles native C SQLite to WebAssembly, backed by the Origin Private File System (OPFS). Delivers native file I/O speed, full SQL support, and ACID transaction guarantees inside Web Workers.
--- FAQs ---
Q: Which local-first database should I use for relational data?
A: For relational Postgres applications, Zero, ElectricSQL, and PowerSync offer high-performance SQL/relational sync models. Zero excels at sub-millisecond client query streaming, while ElectricSQL and PowerSync bring full client-side SQLite WASM execution.
Q: When should I use a CRDT library like Automerge or Yjs instead of a sync database?
A: Use Automerge or Yjs when building document-centric or rich-text applications (like Notion, Figma, or collaborative text editors) where fine-grained concurrent editing of unstructured trees or text spans requires mathematical intent preservation.
Q: How does SQLite WASM function in local-first web applications?
A: SQLite WASM compiles the C SQLite database engine into WebAssembly, running inside browser web workers backed by Origin Private File System (OPFS) storage for native-speed persistence and SQL query capability.
================================================================================
## MODULE 5: THOUGHT LEADERSHIP, PIONEERS, RESEARCH LABS, AND COMMUNITY INSTITUTIONS
Author: Adam Wiggins | Published: 2026-05-26
Description: A comprehensive profile of the researchers, laboratories, open-source maintainers, and community conferences driving the local-first software movement.
The local-first software movement was formalized by research contributions from independent laboratories, open-source developers, and specialized engineering startups[1]. Ink & Switch, an industrial research lab founded in 2018, serves as the movement's primary research engine[1]. Key figures include Dr. Martin Kleppmann (author of *Designing Data-Intensive Applications* and lead researcher on Automerge), Peter van Hardenberg, Adam Wiggins, Mark McGranaghan, Aaron Boodman (founder of Rocicorp), and Steve Ruiz (creator of tldraw)[1]. Community development is centered around the annual Local-First Conference hosted in Berlin[2].
## Key Entities and Institutional Bios
### Ink & Switch
An independent research laboratory dedicated to digital tools for thought, malleable software, and distributed data systems[1]. The lab has published over 40 research projects and seminal essays, including *Local-first software* (2019), *Peritext* (2021), *Cambria* (2020), *Keyhive* (2024–2026), and *Patchwork* (2024–2026)[1].
### Dr. Martin Kleppmann
Associate Professor at Johannes Kepler University Linz, former researcher at the University of Cambridge, and lead author of the 2019 local-first paper[1]. Kleppmann authored the Automerge CRDT library and pioneered research on local-first distributed consistency[1].
> "Data ownership is not just a legal or philosophical concept; it is an engineering guarantee that user software continues working regardless of cloud vendor stability." — Dr. Martin Kleppmann
### Rocicorp
Software company founded by Aaron Boodman (co-creator of Greasemonkey and early Chrome engineer)[1]. Rocicorp developed Replicache and launched Zero, bringing query-driven local sync engines to main web applications[1].
### Local-First Conference (LoFi Conf)
The flagship industry gathering held annually in Berlin[2]. LoFi Conf brings together computer scientists, database architects, and application developers to define local-first protocols, access-control models, and performance benchmarks[2].
--- FAQs ---
Q: Who formalized the local-first software movement?
A: The local-first software movement was formalized in 2019 by researchers Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan through their seminal Ink & Switch research essay.
Q: What is Ink & Switch?
A: Ink & Switch is an independent industrial research lab founded in 2018 dedicated to creating digital tools for thought, malleable software, and peer-to-peer data architectures.
Q: What is the Local-First Conference?
A: The Local-First Conference (LoFi Conf) is the flagship annual industry gathering held in Berlin, bringing together computer scientists, database engineers, and application developers.
================================================================================
## MODULE 6: ENTERPRISE IMPLEMENTATION CHALLENGES, SECURITY, AND TRADE-OFFS
Author: Mark McGranaghan | Published: 2026-06-01
Description: An in-depth investigation of enterprise local-first implementation challenges: browser storage limits, schema evolution with Cambria, Keyhive encryption, and server reconciliation.
While local-first software delivers significant user experience advantages, implementing it in production introduces complex architectural trade-offs around client storage constraints, distributed schema evolution, server authority, and end-to-end security[1]. Solving these challenges requires specialized techniques, such as capability-based encryption (Ink & Switch Keyhive), bidirectional schema lenses (Cambria), and server reconciliation engines (Zero)[2].
## Architectural Trade-Offs in Production
### Client Storage Boundaries and Garbage Collection
Browsers enforce quota limits on IndexedDB storage (typically 10% to 80% of available disk space). Local-first applications managing large datasets must implement LRU (Least Recently Used) cache eviction policies or partial synchronization queries (as pioneered by Zero) to avoid exceeding browser limits[1].
### Distributed Schema Migrations (Project Cambria)
In centralized cloud apps, database schema migrations execute in a single managed step. In local-first systems, thousands of client devices may run different versions of the application simultaneously[1]. The system must resolve schema mismatches gracefully. The Cambria project addresses this by introducing bidirectional lenses—declarative mapping code that translates client data structures between different schema versions on the fly (e.g., transforming `name: "Alice Smith"` in v1.0 to `firstName: "Alice", lastName: "Smith"` in v2.0) without altering the underlying disk state[1].
```
Device A (v1.0 Schema) <--- Cambria Bidirectional Lens ---> Device B (v2.0 Schema)
[ name: "Alice Smith" ] [ firstName: "Alice", lastName: "Smith" ]
```
### Access Control and Encryption (Project Keyhive)
Traditional applications enforce permissions at the central database layer. Local-first applications sync data directly to client hardware, meaning local files must be encrypted to protect user privacy[2]. Ink & Switch's Keyhive project resolves this using capability-based cryptography and dynamic key delegation graphs[2]. Keyhive enables fine-grained access control across distributed devices without exposing plaintext content to intermediate relay servers[2].
### Conflict Resolution vs. Server Business Logic
CRDTs handle concurrent mutations at the data structure layer, but business logic conflicts (e.g., preventing a negative account balance) require server validation[1]. Modern frameworks combine client-side optimistic UI updates with server reconciliation: local writes execute immediately, while an authoritative server checks business rules asynchronously, reverting invalid mutations if necessary[1].
--- FAQs ---
Q: How do local-first applications handle schema migrations across distributed devices?
A: Local-first apps use schema lenses (such as Ink & Switch's Cambria project) to translate data structures dynamically between different version versions bidirectionally without requiring synchronous database migrations.
Q: How does access control and end-to-end encryption work in local-first apps?
A: Capability-based cryptography (like Ink & Switch's Keyhive project) grants fine-grained permissions via dynamic key delegation graphs, encrypting data on-device before relaying through untrusted cloud servers.
Q: What happens when client browser storage quotas are reached?
A: Applications implement partial sync subscriptions (e.g. Zero ZQL queries) or LRU cache eviction algorithms to sync only active working sets locally while keeping deep history backed up in cloud storage.
================================================================================
# PART 2: CHRONOLOGICAL TIMELINE (2018-2026)
Date: 2018-02-15 | Category: Research Lab
Event: Ink & Switch Founded / Early Explorations
Description: Ink & Switch established as an independent research lab focusing on tools for thought, dynamic media, and peer-to-peer data architectures.
Date: 2018-05-10 | Category: Research Project
Event: PixelPusher Project Published
Description: Ink & Switch releases PixelPusher, an early exploratory project utilizing Conflict-free Replicated Data Types (CRDTs) to power real-time collaborative pixel art drawing.
Date: 2018-11-20 | Category: Opinion / Essay
Event: "Slow Software" Essay Published
Description: Ink & Switch publishes "Slow Software: Observations on Latency," detailing network latency degradation in cloud apps and proposing local data execution.
Date: 2019-04-30 | Category: Seminal Essay
Event: "Local-First Software" Paper Released
Description: Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan publish the foundational essay "Local-first software: You own your data, in spite of the cloud," defining the 7 core ideals.
Date: 2019-11-12 | Category: Application Research
Event: Muse / Capstone Research
Description: Research on tablet-based spatial canvas tools yields Capstone and Muse (later renamed Allume), demonstrating local storage performance for creative thinking.
Date: 2020-02-18 | Category: Research Project
Event: PushPin P2P Collaboration
Description: Ink & Switch completes PushPin, exploring commercial-grade peer-to-peer collaboration without central cloud server dependencies.
Date: 2020-08-25 | Category: Protocol Research
Event: Cambria Schema Translation
Description: Release of Cambria, introducing bidirectional lenses to translate distributed data across different schema versions without central migration scripts.
Date: 2021-05-14 | Category: CRDT Research
Event: Peritext Rich-Text CRDT
Description: Ink & Switch publishes Peritext, formulating an algorithm for collaborative rich-text editing that preserves intent across concurrent formatting operations.
Date: 2021-10-08 | Category: Protocol Research
Event: Backchannel Digital Identity
Description: Publication of Backchannel, a relationship-based digital identity architecture engineered to prevent impersonation in distributed local-first systems.
Date: 2022-03-22 | Category: Research Project
Event: Inkbase & Potluck Dynamic Docs
Description: Ink & Switch releases Inkbase (programmable ink) and Potluck (dynamic text documents as personal software), expanding local-first into malleable computing.
Date: 2022-09-15 | Category: Open Source
Event: Automerge 1.0 Stable Release
Description: Automerge reaches 1.0, consolidating JSON-like CRDT data structures in JavaScript and Rust for production adoption.
Date: 2023-04-11 | Category: Research Essay
Event: Upwelling & Embark Essays
Description: Ink & Switch publishes Upwelling (combining real-time editing with version control) and Embark (dynamic documents for planning).
Date: 2023-09-20 | Category: Sync Engine
Event: ElectricSQL v0.6 Released
Description: ElectricSQL introduces v0.6, establishing an open-source sync layer bringing local-first reactivity to Postgres and client-side SQLite.
Date: 2023-11-16 | Category: Academic Benchmark
Event: Princeton GEO Paper Submitted
Description: Aggarwal et al. (Princeton, Georgia Tech, IIT Delhi) submit the first paper defining Generative Engine Optimization (GEO) on arXiv (arXiv:2311.09735).
Date: 2024-05-16 | Category: Conference
Event: Inaugural Local-First Conference
Description: The world's first dedicated Local-First Conference convenes in Berlin, uniting researchers, database engineers, and application creators.
Date: 2024-06-18 | Category: Academic Conference
Event: Princeton GEO Accepted at KDD '24
Description: The Princeton GEO paper is officially accepted and presented at the 30th ACM SIGKDD Conference in Barcelona, introducing GEO-bench.
Date: 2024-06-25 | Category: Sync Engine
Event: Rocicorp Announces Zero (Alpha)
Description: Rocicorp introduces Zero, a general-purpose sync engine utilizing ZQL and zero-cache to deliver sub-millisecond query performance over Postgres.
Date: 2024-09-04 | Category: Technical Standard
Event: llms.txt Standard Proposed
Description: Jeremy Howard (Answer.AI) proposes the /llms.txt standard format to structure website documentation cleanly for LLMs.
Date: 2024-12-18 | Category: Showcase App
Event: Gigabugs Released by Rocicorp
Description: Rocicorp launches Gigabugs, an issue tracker managing 1.2 million rows with Zero and Neon Postgres to prove real-time local sync at scale.
Date: 2025-01-20 | Category: Research Essay
Event: Malleable Software Essay
Description: Ink & Switch publishes "Malleable Software: Restoring user agency in a world of locked-down apps," bridging local storage with end-user modification.
Date: 2025-05-26 | Category: Conference
Event: Local-First Conf 2025 (Berlin)
Description: Second annual Local-First Conference in Berlin, featuring research on access control, sync performance, and local AI integration.
Date: 2025-08-04 | Category: Security / AI Search
Event: Perplexity Bot Evasion Exposed
Description: Cloudflare exposes undeclared Perplexity crawlers rotating user-agents, prompting standard user-agent configurations for AI transparency.
Date: 2025-11-12 | Category: Research Lab
Event: Keyhive & Patchwork Lab Notes
Description: Ink & Switch releases lab notes for Keyhive (capability-based local-first encryption) and Patchwork (malleable collaborative substrate).
Date: 2026-03-07 | Category: Academic / GEO
Event: GEO-SFE Hierarchy Paper Released
Description: Publication of arXiv:2603.29979 (GEO-SFE), establishing how document macro-structure, meso-chunking, and micro-styling drive AI citations.
Date: 2026-04-30 | Category: Industry Standard
Event: Canonical 150-Term GEO Glossary
Description: Digital Applied releases the comprehensive 150-term GEO vocabulary defining platforms, RAG retrieval mechanics, and citation metrics.
Date: 2026-05-18 | Category: Architecture Guide
Event: Smashing Magazine Local-First Feature
Description: Publication of "Architecture for Local-First Web Development," establishing production guidelines for SQLite WASM, Zero, and sync layers.
Date: 2026-06-10 | Category: Sync Engine
Event: Rocicorp Ships Zero 1.0 Stable
Description: Rocicorp officially tags Zero 1.0, marking the first stable release of its general-purpose sync engine with full API guarantees and Supabase hooks.
Date: 2026-07-12 | Category: Conference
Event: Local-First Conference 2026
Description: The 2026 Local-First Conference opens, gathering global engineering teams building offline-first, CRDT-driven production applications.
================================================================================
# PART 3: FRAMEWORK & SYNC TECHNOLOGY MATRIX
Name: Zero (Rocicorp) (https://zero.rocicorp.dev/)
Category: Relational Sync Engine
Client Engine: IndexedDB / Memory | Backend Target: PostgreSQL
Sync Protocol: WebSocket / ZQL Incremental
Key Strengths: Sub-millisecond query execution, scale to millions of rows, declarative ZQL authorization
Description: General-purpose relational sync engine combining client-side IndexedDB caching with zero-cache Postgres replication for sub-millisecond queries.
Name: ElectricSQL (https://electric-sql.com/)
Category: Relational Sync Layer
Client Engine: SQLite WASM / Client DB | Backend Target: PostgreSQL
Sync Protocol: Postgres Logical Replication
Key Strengths: Pure SQL client execution, open-source Postgres sync, shape-based partial sync
Description: Open-source sync layer bringing local-first reactivity to Postgres and client-side SQLite database engines.
Name: Automerge (https://automerge.org/)
Category: JSON/Text CRDT Library
Client Engine: Memory / Local Storage | Backend Target: Any (Peer-to-Peer / Relay)
Sync Protocol: Binary Change Sync Logs
Key Strengths: Complex collaborative documents, rich text intent preservation, offline-first data structures
Description: Data structures library in JavaScript and Rust for building collaborative, local-first applications with full history.
Name: Yjs (https://yjs.dev/)
Category: Structural CRDT Engine
Client Engine: Memory / IndexedDB | Backend Target: Any (WebSocket / WebRTC)
Sync Protocol: Compact Delta Encoding
Key Strengths: Ultra-fast document editing, robust rich-text bindings, extensive ecosystem integration
Description: High-performance CRDT framework supporting rich text, shared types, and editor bindings for ProseMirror, Monaco, and Slate.
Name: PowerSync (https://www.powersync.com/)
Category: Relational Sync Engine
Client Engine: SQLite WASM / Native | Backend Target: Postgres, MySQL, Mongo
Sync Protocol: Streaming Sync Gateway
Key Strengths: Multi-database backend support, client SQL execution, dynamic access control rules
Description: Sync engine connecting client-side SQLite to PostgreSQL, MySQL, or MongoDB with real-time streaming updates.
Name: RxDB (https://rxdb.info/)
Category: Reactive Database
Client Engine: IndexedDB, RxStorage | Backend Target: CouchDB, GraphQL, REST
Sync Protocol: Push/Pull Replication Plugins
Key Strengths: Reactive query subscriptions, flexible storage adapters, encryption and schema validation
Description: Reactive, client-side NoSQL database for JavaScript applications with pluggable storage adapters and sync plugins.
Name: PouchDB (https://pouchdb.com/)
Category: Document Database
Client Engine: IndexedDB / WebSQL | Backend Target: Apache CouchDB / Cloudant
Sync Protocol: CouchDB Multi-Master Replication
Key Strengths: Battle-tested document sync pioneer, robust offline replication protocol
Description: Battle-tested JavaScript database designed to emulate CouchDB and synchronize seamlessly over HTTP.
Name: InstantDB (https://www.instantdb.com/)
Category: Graph-Relational Sync
Client Engine: Client Memory Cache | Backend Target: PostgreSQL (Triple Store)
Sync Protocol: Server-pushed subscriptions
Key Strengths: Firebase-like simplicity with relational graphs, instant optimistic updates
Description: Client-side graph database that syncs automatically with server storage for relational data handling with Firebase simplicity.