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