The Local-First Flywheel

Created Aug 30, 2026 | Published Aug 31, 2026 | Last Modified Sep 01, 2026 | 4 min read

WARNING: thar be speculative fiction!

Work in progress! Please help refine these ideas with me!

The Local-First Flywheel (Big Picture)

… But what specific functional value?

People move for carrots, not sticks. What are the carrots of Local-First?

The Local-First Flywheel (Zoomed In)

Origin of Local-First

The Local-First manifesto: https://www.inkandswitch.com/essay/local-first/

The manifesto was for individual users, what if it was communal instead?

Carrots of Communal Local-First

  1. Unity / Coherence: while platforms want to keep you in their “fief”, as more and more data returns home we gain the most value from unity and coherence between our datas and applications.
    1. Interoperability: to realize unity and coherence, datas and applications must allow for a high degree of interoperability.
      1. Single Pane of Glass: while the platform norm has balkanized producing tens of messaging and event apps, the interoperability of applications can enable these applications to become re-unified.
        1. Example: a self-hosted messaging application which unifies separate messaging services and provides a single UI and control plane for them. Provided translation schemas are defined at the level of the data (e.g. there’s a translation to and from the origin data schema to the local data schema) and API (e.g. each messaging app pulls and pushes data from the correct application-specific endpoints) in theory this is possible.
    2. Composability: coherence can occur at many scales, and composability represents interoperability at the application-level.
      1. Example: Obsidian’s internal plugin approach is an example of such composability, but one could imagine application-specific plugins, e.g. a self-hosted calendar could have its own plugin in Obsidian, allowing seamless composability.
    3. (Speculative!) Bottom-Up Objectivity: through unity there’s greater ability to version and cryptographically sign all data, ensuring integrity and a high degree of verifiability and tamper-resistance within and between datas and applications. In theory this creates the possibility of a bottom-up objectivity.
      1. Device-Level Signing: the devices that produce streams of audio, video, image, signaling, biometric, etc data can have their own local key material which is used to sign chunks of data. This device-level cryptographic signing can be used to ensure all data streams are tamper-resistant.
    4. (Speculative!) Embodied Tech
      1. New Sensory UIs:
        1. Examples: haptics, olfactory, light, etc.
    5. (Speculative!) Application Workflows
      1. Cybernetic Feedback Loops:
        1. Examples: start of party, use volume + upbeat music and warm lights to enliven, as party peaks, dampen with lower volume + downbeat music and cool colors.
  2. “Dunbar Tech”
    1. Lower the Stakes
      1. Trusted community
        1. Example: if sensitive applications require per-user key material that’s produced only on-premise (e.g. when users join the physical wifi network, or when it’s specifically granted) and stored securely on the device, this security model significantly reduces possible attack vectors.
          1. Prosocial Incentives: coliving provides a forcing function for prosocial behaviors and outcomes because we live together and are stuck together in an infinite game. Being forced into an infinite game means it’s best to adopt win-win behaviors.
      2. Lower reliability needs”: hosting for max 100-150 people has very different reliability standards than for millions of people.
        1. Cloud for scale, Localfirst for fam: Localfirst doesn’t produce substituting Cloud but complementing it.
        2. (Speculative!) Simplified Stack The cloud development stack is complex because it’s designed for hyperscale and hyper-reliability. In theory could the localfirst stack be re-simplified because of lower stakes?
      3. Cheap: Local compute is sufficiently inexpensive that communities can own and maintain their own infra, at least for the important stuff.
        1. Sharing / Effort Multipliers: Effort by one person can benefit N people recurrently.
    2. (Speculative!) Natural Federation Properties:
      1. Natural Holonic Levels: Individual server(s) ⇒ Communal server(s) ⇒ Neighborhood server(s)
        1. Example: libraries + backups at each level
      2. Horizontal Scaling: Scale per community or per home.
    3. (Speculative!) Incubation: in the world today we don’t have a ton of good incubation environments for new applications. Coliving could be an ideal incubation environment.
      1. Start with Personal Server, Then Communal: Test local applications on individual server
      2. Full Feedback Loop at Home:
    4. (Speculative!) Graph Properties of Networks
      1. Serendipity: Both at social-level and application-level
        1. Spontaneous Coordination:
          1. Examples: application workflows + serendipity = emergent meeting
  3. Privacy: Your data is your own and you know where it lives and how it’s used.
    1. Example: Local AI. Identity + key management.
  4. Offline: If your home network is running, your applications are usable (at least on-premise), even if there’s a broader network outage.
    1. Example: This applies at the application-level as well — data replication at the device-level means that applications are standalone by design — you can continue to use them irrespective of home or broader network.
  5. Durable Data:
    1. Archiving, Out of the Box: By syncing from platforms, by default you get an archived copy; even if you continue to use the platform service, you now have a backup that makes it resilient to data loss.