astrolabe/docs/exploration/monetization-and-sync-exploration.md

# Monetization & Sync — Exploration

> **Status:** Exploration, not a commitment. Captured 2026-06-10 from a strategy
> conversation. Nothing here is scheduled or in the plan; this is a memo to return to
> later so the _reasoning_ — not just the conclusion — survives.
>
> **Question:** If Astrolabe were ever monetized — e.g. a login that stores encrypted
> snippets in a database — what would that look like, technically and as a product?
>
> **Short answer:** The naive version (mandatory account, cloud-stored library) betrays
> the project's stated identity and isn't worth building. The version that survives
> scrutiny is the _opposite_ of a database: **private "bring-your-own-cloud" sync** that
> moves the user's own library between their own machines through storage they already
> control, with no server, no account, and no data custody. It's the smallest price and the
> smallest severity — and it barely dents the SOUL. Charging for it, if at all, is a
> one-time fee or donations, not a subscription.

---

## 1. The tension this collides with

A login + encrypted-DB system isn't a neutral feature add. [`SOUL.md`](../../SOUL.md) makes
"no account" a **named value**, and lists the opposite under _What We're Not_:

- Value #5, _Own Your Data_: "Your library is a file you control, **not a row in someone's
  database**."
- _Not a collaboration platform_: "No multi-user, **no sync**, no comments."
- _Not a server app_: "**No account system.** No backend, no rendering service."

So there are really two different proposals hiding in the question:

1. **Mandatory account, cloud-stored library** — monetizes by making the cloud the _home_
   of the data. This turns "a file you control" into "a row in our database," the exact
   thing the product is defined against. **Rejected** regardless of revenue.
2. **Optional, opt-in sync layered on a local-first app that still works fully offline with
   no account** — monetizes _without_ touching the soul. This is the only branch worth
   exploring, and it's well-trodden (Obsidian: free local app, paid Sync/Publish; the free
   local app _is_ the marketing for the paid layer).

Everything below lives in branch 2. If branch 1 is ever wanted, the honest move is to
change `SOUL.md` **first**, deliberately — not to let the product drift into it.

---

## 2. The options, and why most were set aside

| Option                          | What it is                                                        | Verdict                                                          |
| ------------------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------------- |
| Mandatory account + cloud DB    | Cloud is the canonical home of the library                        | **Rejected** — betrays the SOUL outright                         |
| Hosted E2EE sync (subscription) | We run a zero-knowledge server holding ciphertext blobs           | **Too heavy** — see §4; disproportionate at our scale            |
| Publish / embed                 | A snippet (or library) opens at a shareable URL                   | **Deferred** — bigger soul-violation + contested market; see §5  |
| **Private-move BYO-cloud sync** | Library rides the user's _own_ cloud between their _own_ machines | **Chosen direction** — smallest price, smallest severity; see §6 |

---

## 3. Build vs. "buy" vs. BYO — the real axis

"Buy the sync engine" was a confusing phrase: it never meant _pay money_. The recommended
engines (Evolu, Jazz) are themselves open source. The axis that matters is three rungs:

1. **Build it yourself** — write the crypto, the sync protocol, and the server. A sync
   engine is doing six jobs, and each is a place to silently lose or leak data: change
   tracking, push/pull, conflict resolution, encryption + key recovery, auth, and the
   server. **Building the crypto/sync core yourself is one of the most bug-prone things in
   software** — failures are catastrophic _and_ silent ("a library quietly corrupts and the
   user notices when it's gone"). Wrong rung for a first foray.
2. **Open-source engine, you host it** — the hard logic is the library's (Evolu = local-
   first + E2EE + SQLite, the closest fit; Jazz = adds auth/permissions; PouchDB+CouchDB =
   battle-tested replication but _not_ E2EE by default). You run a server (Cloudflare
   Workers keeps fixed cost near zero).
3. **Open-source engine, someone else hosts it** — you pay them to run the server; you
   still write the client. The _only_ rung that costs money, and all it buys is "not
   running a server."

So open source absolutely does it. Money only ever buys away the operational burden — and
the chosen direction (§6) removes the server entirely, so it doesn't even arise.

---

## 4. Why charging money is the heavy part (not the code)

The engine is the easy 20%. Taking payment changes the _category_ of the project, inheriting
obligations that have nothing to do with code:

- **Data custody, forever.** You hold the canonical copy. A server loss or a sync-corruption
  bug is _their work gone, and they paid you to keep it safe._ E2EE makes this **worse**:
  you can't read the ciphertext, so you can't inspect or repair damage either.
- **The "can never walk away" tax.** A free local app is static files — stop touching it and
  it keeps working. A paid server-backed service breaks for every paying customer the day
  you stop paying the hosting bill. You've converted "ship it and move on" into "responsible
  indefinitely."
- **Uptime, support, and the forgotten-passphrase trap.** With E2EE, "recover my data" has
  the answer "I can't," and users will be angry.
- **Billing + tax + legal.** International VAT/sales-tax (offload to a merchant-of-record
  like Paddle/Lemon Squeezy), plus privacy policy, ToS, account deletion.

**The proportionality insight — and it cuts against scale.** Almost every obligation above
is _fixed, not per-user_. So the economics are **worst** at small scale: maximum fixed
responsibility, minimum revenue to justify it. 50 users × $5/mo = $250/mo against a forever
guarantee of their data's survival, support, on-call, and never abandoning it. For a small,
passionate audience and a builder who isn't chasing profit, full paid-custody sync is
plausibly a _bad trade even when well-intentioned._ The danger was never "money grab" — it's
that the responsibility dwarfs both the money and the community it serves.

---

## 5. The Vega-editor insight (and how it defuses "publish")

The Vega editor's **share** feature is _itself_ bring-your-own-cloud: "share" doesn't write
to a Vega server — it writes to _your_ GitHub Gist and hands you a URL that renders that Gist
**client-side** in anyone's browser. The editor is a pure client; GitHub is the storage.

Two consequences:

1. "Like the Vega editor, but for a whole library" and "BYO-cloud" are the **same idea** —
   and the tool Astrolabe descends from already proves it works with zero server and zero
   custody.
2. It defuses the earlier worry that _publish_ violates the SOUL's "no rendering service."
   It only does if _we_ run the renderer. If a snippet lives in the user's own storage and
   renders **client-side in the viewer's browser**, there's no backend we operate and the
   data still belongs to the user. The SOUL survives.

Publish was still **deferred** (not killed): bigger soul departure than private sync, and it
walks into Datawrapper/Flourish's contested, free-tier territory. Private-move is the cleaner,
less-contested wedge.

---

## 6. The decision: private-move BYO-cloud sync

The chosen direction. The point is **me getting my own library onto my other machine** —
not showing charts to others. Storage is private; there is no "viewer," just me.

Why it's the smallest price: it's barely a new system. Private-move sync is essentially
**"continuous export/import to a file the user holds, plus a merge rule."** The export
format already exists, so this adds a live file handle and a conflict rule on top of
something shipped — no infrastructure, no account, no encryption-key-recovery burden. The
user's own cloud supplies the auth and the durability for free.

Three decisions define the whole feature:

1. **Transport.** The user points Astrolabe at a file (via the File System Access API) that
   lives inside their Dropbox/iCloud/Drive folder. Astrolabe reads/writes the library doc
   there; _their_ cloud moves it between machines. We never see the bytes.
   **Caveat:** the File System Access API is Chromium-only — on Firefox/Safari, fall back to
   the manual export/import already shipped. So "automatic" is a Chromium upgrade over a
   baseline that works everywhere.
2. **Conflict rule.** Two machines edit offline, both write the file. Per-snippet
   last-write-wins with a version stamp, surfacing a visible "conflicted copy" duplicate
   when stamps clash (Dropbox's own behavior — and exactly SOUL value #6, _predictable, not
   clever_). This is the only genuinely new logic, and it belongs in `core/` where it's
   testable.
3. **Format.** Essentially the existing export doc, perhaps with per-snippet version stamps
   added. An extension of a schema, not a new one.

**Monetization, if any:** a **one-time purchase** (fits "not a money grab," no recurring-
billing or expired-subscription support load, matches an audience that distrusts
subscriptions), or **donations / GitHub Sponsors** for pure sustainability that gates
nothing. Not a subscription.

---

## 7. SOUL impact — minimal

This barely touches the SOUL, which is the point. _Local-by-default_, _own-your-data_,
_no-account_, _no-server_ all stay literally true — "your library is a file you control"
becomes **more** true, since it's now a real file in the user's own cloud. The only line
needing softening is "no sync," and single-user move-my-own-library isn't the multi-user
**collaboration** that line was written to exclude. The deliberate SOUL amendment shrinks to
roughly one sentence.

---

## 8. If/when this is revisited — next steps

- **Validate the need first, for free.** Export/import is already a manual sync ("export,
  drop in Dropbox, import on the other machine"). If people won't do _that_, they won't pay
  for the automatic version — and you've learned it without building anything.
- **Map the three touch-points** before committing: the `app/infrastructure/` file-handle
  adapter, the `core/` merge rule (with tests), and the one-sentence `SOUL.md` carve-out.
- **Decide the conflict UX deliberately** (likely a `/council` question): how the
  "conflicted copy" surfaces to the user.
- **Never DIY the crypto** if this ever grows toward hosted/E2EE — reach for Evolu/Jazz.
- **Keep the core free, local, and offline forever.** It's both the soul and the growth
  engine; the moment a power user hits a paywall on the thing the app _is_, the word-of-mouth
  that local-first products live on is lost.