Local-First
The cloud is optional. Local-first software works on your device, with or without an internet connection.
The Problem with Cloud-First
Most modern apps are thin clients to cloud services:
| User Problems | Server Risks |
|---|---|
| No internet = no app | Service shuts down |
| Latency on every action | Company acquired |
| Can't work offline | Terms change |
| Privacy concerns | Data breach |
Your data hostage to connectivity and corporate decisions
Local-First Principles
Local-first software:
| Principle | Description |
|---|---|
| Works offline | Full functionality without internet |
| Stores data locally | Your device has the complete dataset |
| Syncs when possible | Updates merge when you reconnect |
| You own the data | Files you can backup, export, migrate |
| Fast | No network latency for local operations |
| Long-lasting | Works decades from now |
| Secure | Data encrypted, keys under your control |
The Spectrum
| Cloud-First | Cloud-Optional | Local-First |
|---|---|---|
| Google Docs | Mobile apps | Git |
| Notion | Email clients | Obsidian |
| Figma | Note apps with offline | CRDT apps |
| Slack | Nostr clients |
Local-First in SAND
Solid Pods
While pods are typically servers, nothing prevents running a pod locally:
| Approach | Description |
|---|---|
| Local pod | Your laptop runs a Solid server |
| Sync to cloud | Optionally replicate to a remote pod |
| Work offline | Full access to your data anytime |
| Hybrid | Local pod syncs to cloud pod |
Nostr
Nostr is inherently local-first:
- Identity is your key (no server needed)
- Events cached locally
- Multiple relays = no single point of failure
DIDs
Decentralized identifiers are local by nature:
| DID Method | Local-First Aspect |
|---|---|
| did:key | Identity IS the key pair, stored locally |
| did:nostr | Same—your npub is your identity |
| did:web | Requires resolution, but key stays local |
Sync and Conflict Resolution
The challenge with local-first: what happens when two devices edit the same data offline, then reconnect?
Solutions
| Approach | How It Works | Trade-offs |
|---|---|---|
| CRDTs | Data structures that automatically merge | Complex to implement |
| Operational Transform | Merge edits like Google Docs | Requires server |
| Last-write-wins | Most recent edit wins | May lose data |
| Manual resolution | User decides (like Git) | Requires user attention |
CRDTs (Conflict-free Replicated Data Types)
CRDTs are the gold standard for local-first sync:
CRDT Properties:
- Commutative: A + B = B + A
- Associative: (A + B) + C = A + (B + C)
- Idempotent: A + A = A
No conflicts by design
| CRDT Library | Language | Features |
|---|---|---|
| Automerge | Rust/JS/Swift | JSON-like documents |
| Yjs | JavaScript | Rich text, fast |
| Diamond Types | Rust | Text-focused |
| cr-sqlite | SQLite | CRDT database |
Benefits
| Cloud-First | Local-First |
|---|---|
| Requires internet | Works offline |
| Server latency | Instant response |
| Data on their servers | Data on your device |
| Service can shut down | Your data persists |
| Privacy concerns | Data stays local |
| Subscription required | Own it forever |
| Updates may break things | You control updates |
Trade-offs
Local-first isn't free:
| Challenge | Consideration |
|---|---|
| Storage | Your device needs space for all your data |
| Sync complexity | Merging distributed data is hard |
| Initial setup | May need to sync a large dataset first |
| Multi-device | Need good sync infrastructure |
| Backups | You're responsible for your data |
| Search | Full-text search harder without server |
Local-First Architecture
Sync layer is optional — app works fully offline
Real-World Examples
| App | How It's Local-First |
|---|---|
| Git | Full repo history locally, syncs via push/pull |
| Obsidian | Markdown files on disk, optional sync |
| VS Code | Local files, optional remote |
| Bitcoin wallets | Keys local, sync via blockchain |
| Nostr clients | Events cached, keys local |
Getting Started
- Choose local-first tools — Obsidian for notes, Git for code
- Run a local pod — Sandymount can run locally
- Store keys locally — Use Noskey or Amber for Nostr keys
- Backup — You're responsible for your data now
- Learn CRDTs — Understand how sync works
The Seven Ideals
From the foundational Ink & Switch paper:
| Ideal | Description |
|---|---|
| Fast | No network round-trips |
| Multi-device | Works on all your devices |
| Offline | Full functionality without internet |
| Collaboration | Real-time with others |
| Longevity | Works in 50 years |
| Privacy | You control access |
| User control | Your data, your rules |
Learn More
- Solid Protocol — Pod architecture
- Nostr Protocol — Relay and client model
- Ink & Switch: Local-First Software — Foundational essay
- CRDTs.tech — CRDT resources