mirror of
https://github.com/olehomelchenko/astrolabe.git
synced 2026-08-08 02:02:33 +00:00
Capture the monetization & sync exploration as a standing memo
This commit is contained in:
@@ -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.
|
||||
Reference in New Issue
Block a user