mirror of
https://github.com/olehomelchenko/astrolabe.git
synced 2026-08-08 10:12:34 +00:00
54 lines
3.2 KiB
Markdown
54 lines
3.2 KiB
Markdown
# AI Augmentation — Exploration
|
|
|
|
> **Status:** Exploration, not a commitment. Captured 2026-06-27 from a strategy
|
|
> conversation. The conclusion is folded into [`SOUL.md`](../../SOUL.md) (_Local-Only by
|
|
> Default_ and _Not an AI tool_); this memo keeps the _reasoning_ — including the security
|
|
> analysis behind rejecting browser-stored keys — so a future "should we add AI?" session
|
|
> doesn't re-derive it.
|
|
>
|
|
> **Question:** Most tools shipping in 2026 carry some AI/LLM augmentation. Should
|
|
> Astrolabe?
|
|
>
|
|
> **Short answer:** No — and the user benefit, not purity, is the reason. With no server,
|
|
> no account, and no AI, nothing the user makes is handled by a third party, so Astrolabe
|
|
> is safe for confidential and work data from the first chart. "Everyone ships AI in 2026"
|
|
> is the weakest possible reason to add it: ubiquity makes AI table-stakes noise, not
|
|
> differentiation, and a tool that demonstrably keeps your data on your machine is
|
|
> differentiated _because_ it resists the trend.
|
|
|
|
---
|
|
|
|
## 1. Where AI would genuinely fit, if ever
|
|
|
|
Two spots where Vega-Lite is actually painful and rules can't help but a model could:
|
|
natural-language authoring (NL → spec) and explaining/decoding the editor's opaque
|
|
validation errors. The obvious third — "recommend a chart from my data" — is **already
|
|
solved deterministically** by the Chart Builder's rule-based inference, and the rule-based
|
|
version is better here because it's explainable and runs locally. So the genuine surface is
|
|
narrow.
|
|
|
|
## 2. Why browser-stored BYO keys were rejected
|
|
|
|
The only AI model consistent with "no server, no account" is bring-your-own-key, called
|
|
direct browser → provider (never proxied through a server we run, which would put us back in
|
|
the data-custody business). The blocker is key storage:
|
|
|
|
- A browser has **no secure vault for a secret you must read back**. localStorage,
|
|
IndexedDB, cookies — all readable by any same-origin JS, devtools, and extensions. Client
|
|
encryption only helps if the unlock secret isn't _also_ stored, i.e. a passphrase typed
|
|
each session; a key kept beside its ciphertext is theater.
|
|
- The dominant threat is therefore **same-origin script execution (XSS)**, and Astrolabe is
|
|
unusually exposed to it: it renders arbitrary user specs through vega-embed, whose
|
|
expression evaluator and data loader are a real script-execution / exfiltration surface.
|
|
Holding a secret in that origin upgrades any spec-driven bug from "annoying" to "steals
|
|
the user's key." **Introducing a stored secret raises the threat level of the whole app,
|
|
the chart renderer included** — the opposite of what the privacy posture exists to do.
|
|
- The one mitigant: LLM keys are revocable and spend-cappable, so the blast radius is "bill
|
|
abuse until you rotate it," not data loss. That's why the industry tolerates browser BYOK
|
|
at all — but it doesn't undo the origin-coupling above.
|
|
|
|
**If AI is ever revisited:** the only acceptable form is a **session-only** key (held in
|
|
memory, never persisted, re-entered each session) called browser → provider direct, with the
|
|
core staying fully functional and offline for anyone who never engages it. Persisting the
|
|
key is the specific part that compromises the posture.
|