From 0b8c1785fe4891210cb7bb031092fe9848912f93 Mon Sep 17 00:00:00 2001 From: Oleh Omelchenko Date: Wed, 10 Jun 2026 01:33:24 +0300 Subject: [PATCH] Capture the monetization & sync exploration as a standing memo --- docs/monetization-and-sync-exploration.md | 186 ++++++++++++++++++++++ 1 file changed, 186 insertions(+) create mode 100644 docs/monetization-and-sync-exploration.md diff --git a/docs/monetization-and-sync-exploration.md b/docs/monetization-and-sync-exploration.md new file mode 100644 index 0000000..f9e9da4 --- /dev/null +++ b/docs/monetization-and-sync-exploration.md @@ -0,0 +1,186 @@ +# 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.