KSE-0187 (draft): the browser extension runs the shared key.store agent core #126

Open
founder wants to merge 2 commits from kse-0187-embedded-agent-core into main
Owner

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.session cache (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.store directly (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.

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.session` cache (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.store` directly (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.
evolution: KSE-0187 draft — the browser extension runs the shared key.store agent core
Some checks failed
build-release.yml / evolution: KSE-0187 draft — the browser extension runs the shared key.store agent core (push) Failing after 0s
build-release.yml / evolution: KSE-0187 draft — the browser extension runs the shared key.store agent core (pull_request) Failing after 0s
6f30263556
Direction set by the founder 2026-08-16: embed the agent core (shared agent
runtime, persistence on sqlite3mc, realm/VMK crypto, sync client) compiled to
wasm in the extension so key.store companion is a complete device on its own
(Chromebooks), with the native app preferred when reachable and both kept as
enrolled devices — no retire. The core runs in a chrome.offscreen document
hosting a dedicated Worker over the KSE-0185 WASI shim + OPFS; unlock once per
browser boot via a storage.session cache; passkey-PRF ceremony on a
first-party origin page with offline cache. The design constraint that
outranks the rest is visible consistency: every device syncs with the server
directly, same-machine cores also converge over native messaging, writes are
journaled and replayed, conflicts keep the loser as a revision, and no surface
renders entries without a freshness state. Ground truth recorded: the API has
no realm/entry sync yet (greenfield), no CloudKit. Phases 0-5 with exit
criteria; spikes S1-S5 first.
KSE-0187: core in the service worker — JSPI shim first, memory-VFS + encrypted journal fallback; offscreen shape dropped
Some checks failed
build-release.yml / KSE-0187: core in the service worker — JSPI shim first, memory-VFS + encrypted journal fallback; offscreen shape dropped (push) Failing after 0s
build-release.yml / KSE-0187: core in the service worker — JSPI shim first, memory-VFS + encrypted journal fallback; offscreen shape dropped (pull_request) Failing after 0s
Build: SQLite SEE / Redacted SEE compile (pull_request) Successful in 5s
Build: KaiOS / Build (KaiOS) (pull_request) Successful in 34s
Build: Web / Build (Web) (pull_request) Successful in 34s
Build: Linux / Build (Linux x86_64) (pull_request) Successful in 6m31s
Build: Linux / Build (keystore-forge x86_64) (pull_request) Has been skipped
Build: Apple / Check (SwiftLint) (pull_request) Successful in 5m8s
Build: Apple / Build (iOS) (pull_request) Successful in 3m12s
Build: Apple / Build (macOS) (pull_request) Successful in 2m20s
Build: Apple / Build (visionOS) (pull_request) Successful in 33s
cd3271f9bf
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.
Some checks failed
build-release.yml / KSE-0187: core in the service worker — JSPI shim first, memory-VFS + encrypted journal fallback; offscreen shape dropped (push) Failing after 0s
build-release.yml / KSE-0187: core in the service worker — JSPI shim first, memory-VFS + encrypted journal fallback; offscreen shape dropped (pull_request) Failing after 0s
Build: SQLite SEE / Redacted SEE compile (pull_request) Successful in 5s
Build: KaiOS / Build (KaiOS) (pull_request) Successful in 34s
Build: Web / Build (Web) (pull_request) Successful in 34s
Build: Linux / Build (Linux x86_64) (pull_request) Successful in 6m31s
Build: Linux / Build (keystore-forge x86_64) (pull_request) Has been skipped
Build: Apple / Check (SwiftLint) (pull_request) Successful in 5m8s
Build: Apple / Build (iOS) (pull_request) Successful in 3m12s
Build: Apple / Build (macOS) (pull_request) Successful in 2m20s
Build: Apple / Build (visionOS) (pull_request) Successful in 33s
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin kse-0187-embedded-agent-core:kse-0187-embedded-agent-core
git switch kse-0187-embedded-agent-core
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
key-store/key.store!126
No description provided.