Skip to content
OSA-Midnight Oil

Local-First, Literally

The phrase “local-first” gets used loosely. Many tools claim it while still requiring a sign-in, a sync server, a remote license check, or anonymous telemetry. This page documents what local-first means in OSA-Midnight Oil specifically — what we commit to, what we do not, and where the boundary actually sits.

The commitment

A cockpit is local-first when every primary path works without a network. That means:

  • The native binary launches without contacting any server
  • The encrypted vault opens with the master passphrase alone — no remote key check
  • All twelve modules render and operate on local data only
  • Backups produce a file you control, not a remote stored copy
  • Models run locally through ROS-managed runtime adapters
  • No analytics, no crash telemetry, no “anonymous” usage data

If a user puts the device in airplane mode after install, they should notice nothing different.

Where the network exists at all

There are exactly three places network access is allowed:

  1. Outbound update check — the user can manually check for a new release. Off by default, opt-in.
  2. Nostr Lounge — a federated read-first sidecar. Explicitly a networked module. Disabled by default.
  3. F*Society LAN — peer-to-peer discovery on the local network only. No external endpoints.

None of these run on launch. None of them are required for any other module. There is also a Cockpit/Dashboard Stream to tell One when there are LAN Connections or Open Ports to and from ROS.

What we will not compromise on

  • No account system. There is no “Sign in to OSA-Midnight Oil”. The master passphrase is the only credential.
  • No recovery service. A forgotten master passphrase means a destroyed vault. There is no “reset password” link because there is nothing on a server that could reset.
  • No telemetry. Not anonymized, not aggregated, not opt-in-but-defaulted-on. If diagnostics are ever added, they will be explicit, inspectable, and require an affirmative toggle.
  • No remote feature flags. The behavior of the binary is determined by the binary, not by a server’s response.
  • v0.3 We will consider phrase’d mneumonics for recovery in the future.

What paid tiers do not change

Licensed tiers (Founder, Pro, Enterprise) unlock feature flags inside the same local binary. The license validation is offline-first: a cryptographically signed key, validated locally, with a grace period for tier renewal. The license server is consulted on purchase and renewal events, not on every launch and never on every action.

You can run a Pro tier offline for the entire license period.

The trade-offs we accept

Local-first comes with real costs. We accept these explicitly rather than pretending they don’t exist:

  • No real-time multi-device sync. If you use the cockpit on a laptop and a desktop, you move data with the backup bundle or a manual export. There is no magical cloud sync.
  • No “log in from anywhere” recovery. Losing the device with no backup means losing the workspace.
  • No automatic collaborative features. Enterprise collaboration uses F*Society LAN (local network) or explicit handoff bundles — not a real-time CRDT cloud. We can change the name for you guys later. Works like P2P Workground but with encryption and security.
  • Heavier initial install. A real local-first product includes its own dependencies; the binary is not a thin client.

These are not bugs.

Why this stance

The threat model the cockpit takes seriously is not “your password is weak.” It is “your work product is on someone else’s infrastructure.” Every meaningful trust decision in the architecture moves data closer to the operator, never further away.

If that stance matches your needs, the cockpit will feel like the obvious tool. If it does not — if you would prefer a cloud-synced productivity suite with team comments — that tool exists, and is not this one.