Local Authority

Users maintain decision authority locally. Systems prioritize offline operation and don't centralize control.

Definition Summary

What it is: Local Authority means users decide and act locally first, without requiring permission from remote servers. Systems work offline and sync changes eventually, not demand authorization.

Why it matters: Centralized authority is a vulnerability. Networks fail. Servers are compromised. Users in low-connectivity or hostile environments need to remain productive and in control. Local-first design eliminates remote dependency and cascading failures.

When to use: Every system capable of offline operation should. Local authority applies to mobile apps, collaborative tools, sensitive data, and resilience-critical systems. If your system requires internet to function, you're accepting unnecessary risk.

Why Local Authority Matters

Centralized architectures create single points of failure. When servers are unreachable—due to network outage, DDoS, geopolitical censorship, or intentional coercion—the entire system freezes. Users lose both data and autonomy.

Local Authority flips this: users maintain a complete, functional copy of their data locally. They can read, write, encrypt, and act without waiting for server permission. Changes sync when connectivity returns.

This has profound consequences:

Resilience: Network outages don't mean work stoppage. Systems continue functioning.
Autonomy: Users control their data and decisions, not remote servers.
Offline capability: Mobile users, travelers, and those in low-connectivity regions remain productive.
Anti-censorship: Authoritarian control over central servers cannot retroactively revoke user access.
Performance: No latency waiting for round-trips to distant servers.
Privacy: Sensitive decisions can be made entirely on-device; servers see only what users publish.

Implementation Patterns

Offline-First Architecture

Start with local state. All reads and writes happen to local storage first (browser IndexedDB, mobile SQLite, desktop JSON files). Sync to server is secondary—an optimization, not a requirement.

Code sketch:

user.toggleTask(id) → writes to local database immediately
UI updates instantly
In background, diff is computed and sent to server
If send fails, retry later; meantime user continues working

Conflict-Free Replicated Data Types (CRDTs)

When multiple copies of data exist locally (across devices or sessions), conflicts are inevitable. CRDTs resolve these conflicts deterministically without coordinator:

Last-writer-wins: Timestamps decide (works if time trust is okay)
Operational Transform: Record edits as operations; replay them in consistent order
CRDTs: Data structures designed so merging always produces consistent result
Explicit merging: User chooses outcome when conflicts arise (transparent and empowering)

Example: Git is a CRDT. Multiple users edit locally, commit, and merge. Conflicts surface as diffs users resolve.

Eventual Consistency

Stop demanding immediate global consistency. Accept that:

User A on laptop sees change before User B on phone
This is okay; eventual consistency is reached when sync completes
Show users what is synced vs. pending (transparent state)
Design UI to handle "my copy might be outdated" scenarios gracefully

Anti-pattern: Blocking on server round-trip before showing result to user.

No Forced Cloud Reliance

If your system can degrade gracefully, it should. Never architecturally require:

Cloud backup as the only storage
Authentication server contact to use local features
Cloud processing for basic operations
Real-time sync as a hard requirement

Better: "Auto-save to cloud if available; work offline if not."

Peer-to-Peer Sync (Optional)

For maximum resilience, enable users to sync directly without central server:

Two devices on same WiFi share changes directly
Server is optional—nice to have, not essential
Works in censored regions where central server is blocked
Requires investment but dramatically increases resilience

Anti-Patterns (What to Avoid)

❌ Cloud-Only Architecture

System requires internet to function. User clicks "New Document" and gets "No Network" error. Work is impossible offline.

Consequence: Every outage is a productivity crisis. Users in tunnel, airplane, or low-signal area are stuck.

❌ Optimistic Lock Without Offline Support

System allows offline edits but requires server contact to "finalize" them. If server rejects changes (due to newer version), user loses work or is asked to manually merge.

Consequence: Rage. Users feel powerless when system reverts their offline work.

❌ Sync Failures Cascade

One failed sync makes entire app unusable. User can't read new messages, write new notes, or access local data.

Consequence: App feels fragile. Users lose trust in system reliability.

❌ No Transparency on Sync State

User doesn't know if their data has synced. Is this version saved? Is that change backed up? Ambiguity causes anxiety.

Consequence: Users manually export/backup excessively. Friction increases.

❌ Forced Incremental Cloud Features

Release 1.0: Works offline. Release 2.0 adds "Cloud Sync" as paid feature. Release 3.0 makes cloud sync mandatory for new users.

Consequence: Lock-in. Users who want to leave are stranded (their data is only on servers).

Real-World Examples

CouchDB / PouchDB — The Gold Standard

What it is: CouchDB is a document database designed around local-first sync. PouchDB brings this to browsers.

How it works:

Each user's data lives in a local copy (on their device)
They read/write locally with no server latency
When network permits, changes replicate bidirectionally
Conflicts resolved via deterministic merge (last-writer-wins with timestamps)
Server is a passive replica, not a gatekeeper

Why it works: Designed explicitly for offline-first. No surprises, no cloud-only creep.

Figma — Offline Multiplayer

What it is: Collaborative design tool that let teams edit simultaneously, even without internet.

How it works:

Each user's edits are applied to local canvas immediately
Changes are broadcast to other connected users in real-time
If connection drops, users keep working; sync resumes when online
Uses operational transforms to merge concurrent edits

Why it matters: Showed that real-time collaboration doesn't require perfect connectivity. Local authority + smart merging = resilience.

Obsidian — Local Vault First

What it is: Note-taking app where your vault is a folder on your device.

How it works:

All notes live in a local folder (you can access them without Obsidian)
You decide if/how to sync (Obsidian Sync is optional paid service)
You can use any sync service (iCloud, Dropbox, Syncthing, Git)
App works perfectly offline; sync is a convenience, not a requirement

Why it works: Users own their data. They're not locked into vendor sync infrastructure.

Git — Distributed Authority

What it is: Version control where every developer has a local, complete copy of history.

How it works:

You commit locally without contacting any server
You can work offline indefinitely
When you're ready, you push to shared server (GitHub, GitLab)
Conflicts are surfaced explicitly; you merge them locally
Central server is optional; developers can sync peer-to-peer

Why it works: Core design philosophy: "Local authority is normal." No surprises.

Signal Messenger — End-to-End with Local Auth

What it is: Messaging app where encryption keys are generated and stored locally.

How it works:

Signal server never sees message plaintext; it's encrypted before leaving device
User's keys are stored locally (not on Signal's servers)
User can verify safety numbers in-person, proving they control their keys
Server stores encrypted messages temporarily; user fetches them offline then deletes

Why it matters: Even though messaging is network-dependent, authority over keys is local. User controls crypto.

Anti-Example: Microsoft Office Online

What it is: Cloud-only office suite (historically).

The problem:

Internet required. No offline editing (until very recently)
User on airplane cannot work
Outages block productivity
Server is gatekeeper to your own data

Lesson: Cloud-first is a business model, not a security model. It concentrates authority in the vendor's hands.

Scope and Applicability

When to prioritize Local Authority:

Mobility-critical apps (mobile, laptop, offline work)
Resilience-critical systems (medical, emergency response, survival tools)
Privacy-sensitive tools (crypto, dissent, personal finance)
Censorship-prone regions (system must work if server is blocked)
Low-bandwidth environments (sync must be optional, not blocking)
Collaborative tools (multiple users, multiple devices)

When you might defer Local Authority:

Real-time competitive systems where global consensus is essential (stock markets, auctions)
Highly regulated systems where central audit trail is non-negotiable (banking, healthcare)
Prototype/MVP stage (can add later; architectural debt is acceptable short-term)

Never defer for convenience. "Cloud-first is easier" is true for the first 12 months. By month 24, offline users have abandoned you for competitors.

Synthesis Lineage: Disciplinary Roots

Local Authority formalizes patterns observed across multiple established fields:

Local-First Software Movement

The contemporary local-first revolution (Kleppmann, Wiggins, 2019) articulated seven ideals for software:

No requirement for high-bandwidth server
Offline operation by default
Seamless collaboration
Multi-device sync
User data ownership
Encrypted by default (user controls keys)
Long data lifespan (software can be archived/reconstructed)

Protective Computing refines: These ideals describe how to structure *authority*. Local Authority is the architectural expression of "users own their data and decisions locally; servers support but don't control."

Distributed Systems Resilience

Distributed systems theory (Lamport, Fischer et al.) teaches:

You cannot distinguish network partition from server failure (both look like silence to client)
Requiring consensus before proceeding is expensive and fragile
Eventual consistency with offline-capable clients is more resilient than strong consistency
Quorum-based systems still fail when coordination is impossible

Protective Computing applies: Users should never be blocked by unavailable central servers. Local-first design acknowledges network partition as normal and designs around it.

Digital Sovereignty & User Autonomy

Political philosophy of digital sovereignty (Zuboff, Morozov) emphasizes:

Centralized datums enable surveillance and control (whether by state or commercial actor)
User autonomy requires control over their own data and decisions
Decentralized architecture is harder to suppress than centralized
Users should be able to leave a system without losing their data

Protective Computing operationalizes: Local Authority is the technical instantiation of digital sovereignty. Your data on your device, by default.

Offline-First Mobile Architecture

Mobile app design (Fowler, 2009+) established:

Networks are unreliable; apps can't count on connectivity
Users expect mobile apps to work in elevators, tunnels, airplanes
Sync is essential for multi-device scenarios (but must be eventual, not blocking)
Local persistence is non-negotiable

Protective Computing generalizes: These aren't mobile-specific constraints; they're universal truths. All systems should architect as if the network is unreliable.

Security Through Reduction of Authority

Cryptographic and systems security (Saltzer & Schroeder, principle of least privilege) teaches:

Centralize authority → centralize risk
Single server compromise exposes all users
Decentralized decision-making reduces blast radius
Users should be able to make critical decisions without trusting server

Protective Computing applies: Local Authority isn't just convenient; it's a security principle. Distribute authority to reduce attack surface.

Relationship to Other Principles

Local Authority works with:

Reversibility: Offline-first systems can implement better undo/redo (all state is local; rollback is trivial).
Exposure Minimization: Local decision-making keeps sensitive data off servers. Decisions are made on-device without unnecessary transmission.
Coercion Resistance: Having local authority makes you harder to coerce. Attacker cannot demand server surrender your data if server doesn't have it.
Degraded Functionality: Local authority enables graceful degradation. Offline mode is just "degraded connectivity" mode.
Essential Utility: Local authority supports essential function. You can still access critical data and make critical decisions without network.

Next Steps

For system designers:

Audit your architecture: What requires internet? Can offline-first replace it?
Identify "must work offline" features (read, write, sync, crypto)
Choose CRDT or eventual-consistency strategy (operational transforms, last-writer-wins, CRDTs, explicit merge)
Implement local storage first; server sync second
Test offline thoroughly (disable network, kill server, long taxi times)
Make sync state visible to users (showing "synced" vs. "pending")

Related Principles

Reversibility: Local authority enables better undo/redo; all state lives locally, so rollback is trivial.
Exposure Minimization: Local decision-making keeps sensitive data off remote servers. Data stays on user's device.
Coercion Resistance: If users hold encryption keys locally, coercers cannot compel servers to disclose.
Degraded Functionality: Local operation is graceful degradation of connectivity. System works fully offline.
Essential Utility: Local-first eliminates cloud dependencies; essential functions don't depend on remote servers.

Next principle to explore: