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 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:

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.
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:

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.
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).
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:

"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.
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:

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.
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.
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.

11 KiB Raw Blame History Unescape Escape