Locara

48 — Durability: What if Locara Disappears

A core promise of Locara is that apps you install today will keep working forever, even if the project itself is gone. This document spells out exactly what survives, what doesn’t, and how to ensure the long-term durability of apps + data + ecosystem.

This is a public commitment. It’s also engineering work that has to happen in advance — durability isn’t something you add at the end.

The core property

A Locara app installed on your Mac runs without dependence on Locara’s servers, Locara’s infrastructure, or Locara’s continued existence.

If registry.locara.app goes offline tomorrow, every Locara app already on your machine continues to function. You can keep recording with Transcribe, keep ingesting with DocVault, keep using your data, indefinitely.

This works because:

  • Each Locara app is a standalone signed Mac app.
  • The framework code is statically linked into each app.
  • Models are downloaded once + cached locally; no live fetch is needed for use.
  • All data is in local SQLite files in app containers.
  • Inference is fully local — no API calls.

There’s nothing the registry being down can break.

What survives if Locara disappears

Things that fully work

  • ✅ Every installed Locara app continues to launch + run.
  • ✅ All app data (transcripts, documents, settings) remains accessible.
  • ✅ Models in the shared cache continue to work.
  • ✅ Inference, OCR, transcription, embeddings — all work.
  • ✅ Local search, Q&A, all per-app features.
  • ✅ macOS Gatekeeper continues to verify the Apple Developer ID (signed before the project’s end; signature persists).
  • ✅ The OSS code remains under Apache 2.0 forever; anyone can fork.
  • ✅ Apps stored as standalone .app bundles can be backed up, copied to other Macs, archived indefinitely.

Things that degrade

  • ⚠ Update checks fail (they hit registry.locara.app). Apps continue running on whatever version is installed.
  • ⚠ New installs from locara.app website may fail if the website is down. Mitigation: third parties can mirror the catalog; apps can be sideloaded.
  • ⚠ Sigstore provenance verification on first launch may fail if Sigstore is unreachable. Apps cache the attestation after first verification; subsequent launches don’t need network.
  • ⚠ Revocation list checks fail (apps cache the list and continue with the cached version).

Things that stop working

  • ❌ Submitting new app versions to the official registry.
  • ❌ Browsing the official catalog at locara.app if the website is down.
  • ❌ Reading new reviews / ratings.

Durability mechanisms (what we build to make this real)

1. Apache 2.0 license, forever

Every line of Locara code is under Apache 2.0 (per ADR 0009). The license is irrevocable. Anyone can fork, redistribute, modify the framework forever.

Implication: the framework’s source survives any organizational dissolution.

2. Open spec

This spec folder + ADRs + notes are all in the public repository under Apache 2.0. They serve as a complete record of how Locara works. Anyone can implement a compatible runtime, registry, or set of tools from these documents alone.

Implication: the ideas + architecture survive.

3. Open file formats

  • Manifests are JSON.
  • Apps store data in plain SQLite files.
  • Settings, exports, backups all use open formats (JSON, Markdown, CSV, etc.).
  • Models are GGUF (llama.cpp standard) or MLX format (when v2 ships).

No proprietary file formats. A user can crack open any Locara app’s data with sqlite3 from the command line.

Implication: users can extract + carry their data into any future tool, even without Locara.

4. Apps are standalone Mac apps

Per ADR 0012, each Locara app is its own signed .app bundle. They don’t depend on a Locara process running anywhere. They run on macOS the same way any other Mac app does.

Implication: an installed app continues running for as long as macOS supports its build target.

5. Sigstore log + transparency

Every published app’s provenance attestation goes to Sigstore’s transparency log (operated by the Linux Foundation). This log is public, append-only, and auditable.

Implication: even if Locara’s servers go away, the cryptographic record of what was signed when survives in Sigstore.

6. Registry data is exportable + mirrorable

The registry’s app data (manifests, version history, signed attestations) is available as a public JSON export. Anyone can mirror it. Build a competing catalog. Run their own registry against the same spec.

The Locara CDN at cdn.locara.app hosts artifacts. If we go away, mirroring becomes urgent — but the artifacts themselves are bit-identical to what we shipped, signed by Apple Developer ID + Sigstore, and verifiable by anyone.

Implication: the catalog itself can be reconstructed from public data.

7. Independent maintainer succession

Per ADR 0003 + 40-operational-security.md, the project has documented succession + escrow. If the primary maintainer is incapacitated, others can continue.

If the entire team is lost, the OSS code still exists; anyone can fork it.

8. Domain + signing-cert escrow

Critical operational credentials (domain, Apple Developer ID, Sigstore identity) are escrowed with a trusted third party (per 40-operational-security.md).

Even in worst-case organizational dissolution, control of the domain + signing identity can be transferred to a successor entity (e.g., a digital-rights nonprofit acting as steward).

Implication: the brand + signing chain can survive a maintainer crisis.

What users should do for durability

For a user concerned about long-term access to their data:

  1. Time Machine backups. Standard macOS backups capture each app’s container directory. Restorable to any future Mac.
  2. App-level export. Each app has its own export functionality (markdown / JSON / CSV). Export periodically; store somewhere durable.
  3. Save the .dmg. If you really want to be sure, save the original .dmg of the app. You can re-install on a future Mac without needing to re-download.
  4. Save the source repo URL. Most Locara apps are open source; you can rebuild them from source if the framework or app disappears.

What publishers should do for durability

For a publisher who wants their app to outlive Locara:

  1. Publish source publicly (GitHub, Codeberg, etc.). The reference apps are themselves open source.
  2. Document the build. Reproducible builds + clear build instructions in the README.
  3. Hold their own backup of artifacts. Keep .dmg files of each version; survive the registry.
  4. Sign your own artifacts (if they get their own Apple Developer Program). Optional but adds resilience: their app survives even if Locara’s signing chain is unavailable. Most publishers won’t bother; it’s available.

What Locara commits to (operational)

These are published commitments. Future maintainers must honor them or override via new ADR with public justification.

  • The OSS license stays Apache 2.0 for all Locara framework + reference app code. Forever.
  • The spec + ADRs + notes stay public in the canonical repository under Apache 2.0. Forever.
  • Manifest schema versions are supported indefinitely. An app declaring locara/v1 today must run in 2046.
  • Public mirror of registry data at a stable URL (e.g., https://locara.app/registry-mirror.json). Updated nightly.
  • Sigstore log entries are public + permanent.
  • 30-day notice before any breaking change to public APIs, signing chain, or distribution model.
  • At least 12 months of warning before any sunset of the project itself.

Project sunset procedure (theoretical, contingency)

If Locara as a project ever needs to wind down:

  1. 12-month minimum notice announced publicly.
  2. All registry data exported + mirrored to multiple locations.
  3. Domain + signing keys transferred to a designated successor entity (digital-rights nonprofit if no clear successor).
  4. Source repos transferred to a community-maintained organization (or remain at the project lead’s account if successor unclear).
  5. Final framework release marked as the long-term-stable version with a community-maintained successor branch encouraged.
  6. Postmortem published explaining the sunset reasons.

This procedure exists so that “what if Locara goes away” doesn’t depend on goodwill — it’s documented, expected, and survivable.

What this means for trust

The durability commitment is the trust currency of the project. Users trust Locara apps because:

  • The apps themselves keep working forever (architecture).
  • The user’s data is theirs forever (open formats).
  • The framework can be forked + continued forever (open source).
  • The records of what was shipped are auditable forever (Sigstore).
  • Even worst-case sunset has a documented plan (this doc).

This is what “files over apps” looks like at the framework level: not just one app’s data, but the entire ecosystem’s data, durable beyond any single project’s existence.

What this is NOT

  • Not a guarantee against macOS itself changing in incompatible ways. Apple controls the OS; if they break things, we can’t compensate.
  • Not a guarantee against hardware decay. Your Mac will eventually die; your data needs backups.
  • Not a guarantee against you forgetting to back up. Locara is a tool; users still have responsibilities.
  • Not a substitute for the user’s own continuity planning.

We protect against project-failure-mode risk. We don’t protect against universe-level risk.

Open questions

  • (open) Should we publish public release archives (every framework version, every reference app version) on the Internet Archive / IPFS / similar permanent storage for additional resilience? Probably yes; cheap insurance.
  • (open) Should we maintain a public “what would happen if Locara stopped tomorrow” runbook for users? Probably yes; this doc is most of it.
  • (open) Should we incorporate as a nonprofit (vs. company) to better support long-term durability commitments? Open question; depends on legal entity decision.

Cross-references