3.2 KiB
AI Augmentation — Exploration
Status: Exploration, not a commitment. Captured 2026-06-27 from a strategy conversation. The conclusion is folded into
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.