KSE-0187 (draft): the browser extension runs the shared key.store agent core #126
No reviewers
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
key-store/key.store!126
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "kse-0187-embedded-agent-core"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Draft proposal per the founder direction of 2026-08-16: embed the agent core (shared agent runtime, KeyStorePersistence on sqlite3mc, realm/VMK crypto, sync client) compiled to wasm in
key.store companion, so the extension is a complete device on its own (Chromebooks) and a thin bridge that prefers the native app when reachable — both kept as enrolled devices, no retire.Decisions captured: offscreen document + dedicated Worker over the KSE-0185 WASI shim/OPFS; unlock once per browser boot via a
storage.sessioncache (cadence later); passkey-PRF ceremony on a first-party origin page with offline cache; sqlite3mc (not SEE).The constraint that outranks the rest — visible consistency: every device syncs with
api.key.storedirectly (native reachability never decides who receives updates), same-machine cores also converge over native messaging, writes are journaled + replayed, conflicts keep the loser as a revision, and no surface renders entries without a freshness state (in sync (rev N, t)/syncing/offline since t/served by key.store app).Ground truth recorded: the API has devices/passkeys/account/pairings/push relays but no realm/entry sync yet, and there is no CloudKit — sync is greenfield.
Phases 0–5 with exit criteria; spikes S1–S5 (PRF hand-off, sqlite3mc on WASI, offscreen+OPFS lifecycle, storage.session semantics, native-messaging peer framing) come first. Draft — for discussion, not merge-as-decided.
Founder 2026-08-16 (later the same evening): the offscreen document existed only because SQLite's VFS is synchronous and OPFS SyncAccessHandle is dedicated-worker-only. Remove the synchronous requirement instead: (2) JSPI — WebAssembly.Suspending fd_*/fetch/sleep imports over async OPFS with promising entry points, real file semantics in the MV3 service worker, and it retires the KSE-0185 continuation bridges + executor pump on that path ('more experimental, but overall much simpler. I want this'); (1) memory VFS + async encrypted journal as the fallback where JSPI is absent (Firefox, Safari, older Chromium) — 'do 1 and 2'. Both behind the shim's existing FS backend interface, chosen by feature detection, so no minimum_chrome_version bump and no new store permission. Spike S3 becomes the JSPI shim + S3b the fallback; security note on single-activation serialisation under JSPI.View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.