TodoMVC end-to-end demo: integrating the UI surface with the engine, both sync paths, and revocation

[lannbot]

Gap analysis for the first end-to-end product artifact: TodoMVC, multi-device, multi-user, realtime + non-realtime sync, E2E-encrypted, revocation live — the UI surface spike (#15/#16, spikes/todomvc/) joined with the engine spikes (#8/#9, spikes/skeleton/) and the storage layer (#19, spikes/storage/).

Target demo

Alice on two devices + Bob as a collaborator. Alice creates a todo list; edits flow device↔device and Alice↔Bob in realtime (component-iroh) and through a bucket when peers are offline (the pull layer); Bob is revoked mid-demo — his UI stops receiving, his pulls are refused, his history stays readable; a cold device bootstraps from the bucket alone.

What already exists (all green, pinned, unpatched upstreams)

Piece	Where	Status
App-drives-DOM (no app JS), op protocol, deltic browser host	spikes/todomvc (#16)	running, live Pages demo
E2E content: automerge chunks under BeeKEM epochs, sedimentree sync over iroh QUIC, membership over the wire, keyhive-gated pull	spikes/skeleton (3a+3b)	running (wasmtime)
Bucket path: SigV4 in-guest, name-keys, K_p, cooperative revocation, account-less recipient, stolen-device assertion	spikes/storage	running (wasmtime + MinIO)
Identity: one platform-held key backing keyhive + subduction	spikes 1–3	running
Relay interop with stock/n0-prod iroh relays	polymorph-iroh	proven

Nothing below requires new design decisions on transports, crypto, or revocation semantics — those are proven. The gaps are integration, one content-model generalization, one identity-persistence decision, and one browser-host module.

Gaps

G1 — The app↔engine data contract (blocking, small, needs UI-session coordination).
The TodoMVC guest holds its model in memory. The demo needs the app world to grow a data import (or the app composed against the engine's export): todo-shaped for the demo (list/add/toggle/edit/delete + a change-notification stream) rather than the general polymorph:automerge surface (#8) — but shaped so it obviously projects from it. Decide together with the UI session: import-into-app-world vs wac plug app+engine; how change events reach on-event (the surface's event-record path suggests: engine change → framework event record).

G2 — Engine content model: chain → DAG (medium).
The skeleton's spine is a single "msg" key with linear preds. TodoMVC needs real automerge changes as chunks (multi-parent deps = keyhive pred-refs = sedimentree parents — the mapping exists, the plumbing assumes one pred), merge-on-read of concurrent edits, and offline authoring that reconciles later. causal_order already handles DAGs; the authoring/read paths need the generalization, plus doc persistence beyond the "msg" projection (todo list schema).

G3 — User = device group (medium; upstream-supported).
Spikes used per-device doc membership with host-relayed key blobs (labeled stand-ins). The demo story needs keyhive groups: enrollment (paste/QR a contact card; first device adds the new device to the user group), docs delegated to the group, sharing = adding Bob's group. This is #10's minimal slice; everything needed exists in keyhive_core (generate_group, transitive delegation — spike-proven at the doc level).

G4 — One engine, both sync paths (medium-large).
Skeleton (iroh) and storage (bucket) have never run together. Unify: the same keyhive envelope bytes feed sedimentree (realtime) and bucket objects (non-realtime; names already keyed by cref). Replace the storage spike's stand-ins with the real coupling: name-key epochs rotate with BeeKEM epochs; the keyhive op stream stored as blobs under name-keys (this is what makes cold-start and offline-invite work from the bucket alone); K_p wrapped to keyhive contact-card prekeys instead of ad-hoc x25519. Policy: author → put chunk+manifest (+op-stream delta); boot → pull bucket, then live-sync.

G5 — Persistence across restarts (decision + small-medium; gates the browser demo's UX).
Engine state (keyhive archive, sedimentree store, automerge docs) must survive reload: files under wasmtime; IndexedDB/OPFS under deltic. The identity half is the #11 finding: non-extractable keys don't persist without the webcrypto platform-keystore slice (deltic host could structured-clone CryptoKeys into IndexedDB — a host-module feature, not WIT). Decide: (a) memory-only demo identities + re-enroll per session, (b) demo-grade extractable identity persisted encrypted, (c) build the deltic keystore slice now. (c) is the honest one and pays #11 down early.

G6 — The engine's browser leg (medium-large + one empirical risk).
The UI already runs on deltic; the engine has only run under wasmtime. Needed: a deltic wasi:http@0.3 client host module (fetch-backed — likely does not exist yet; the storage fetcher component stays unchanged); verify inter-task-wakeup under deltic (the spike-2 finding was validated on wasmtime only — this is the one thing that could force rework); bucket CORS recipe (MinIO/R2 config — the provider-checker item); compose and size the full browser engine (keyhive + subduction + bridge + automerge + storage + fetcher + iroh endpoint).

G7 — Demo choreography and infra (small).
Relay (local --dev or n0 prod — proven), MinIO or R2 with CORS, a scripted scenario driver (offline window, revocation finale), Pages packaging alongside the existing demo. Stretch: presence via subduction_ephemeral.

Suggested sequencing

1. G1 now — it unblocks parallel work between this session and the UI session; everything else hangs off the contract.
2. G2+G3 → "engine v0.2", validated headless under wasmtime with the full multi-device/multi-user scenario (no UI needed — the spike-host pattern).
3. G4 folds the bucket in (same headless validation: cold-start from bucket only).
4. G5 decision early (it shapes G6's UX); implementation alongside G6.
5. G6 browser leg — with the deltic inter-task-wakeup check first, since it's the only rework-risk item.
6. G7 assembly.

Open questions routed to the UI session: contract shape for G1 (import vs composition; change-event delivery through the event-record path); whether the worker/frame-split seam lands before or after the demo (the engine doesn't care, the threat story does).

[lannbot]

G1 redirect from the system-services design (see the new tracking issue and NOTES §System services): the app↔engine contract should be drafted as polymorph-data:tasks@0.1.0 — the first data service — rather than an ad-hoc todo interface. Same work, seeds the schema-authority pattern, and sets up the follow-on demo (three apps, one service: todomvc + kanban + velocity chart over one shared task partition).

[lannbot]

Status reconciliation after the system-services design round (#21, NOTES §System services):

Net effect on this demo: G1 re-shaped for the better, one micro-decision added, everything else #21 produced is explicitly NOT demo-blocking. The critical path did not get longer.

• G1 (still first, still the coordination point): draft polymorph-data:tasks@0.1.0 — versioned WIT, todo ops + change feed, and a partition identity in the contract so kanban/velocity join later without rework. We will draft unilaterally and post here; the WIT draft is the coordination artifact.
• New micro-decision: demo-v1 topology — serve polymorph-data:tasks from inside the engine composite (tasks logic compiled in) rather than as a separate component. Apps bind the same WIT either way; the schema-authority rule is honored (one authority per partition); the component split is a wac refactor when the three-apps-one-service demo needs it.
• G2–G7 unchanged. G2 is now precisely scoped: the engine doc surface the tasks service consumes.
• Fenced out of demo scope (framework track on System services: schema-authority data services, computed capability profiles, the egress-reachability badge #21): egress-reachability badge, kernel capabilities/appointment path, consent surface, pickers. The demo harness pre-wires grants; no consent UI in the demo.

Next unit: G1 WIT draft + G2 (chain→DAG engine generalization), in parallel.

[lannbot]

G1 + G2 executed and passed — spikes/tasks-engine/ (commit de7d8b2), 5/5 stable runs.

G1: polymorph-data:tasks@0.1.0 (draft contract — this is the coordination artifact for the UI surface)

package polymorph-data:tasks@0.1.0;

interface tasks {
    /// One task.
    record todo-item {
        /// Stable, opaque, unique within the partition.
        id: string,
        title: string,
        completed: bool,
    }

    /// A consistent view of the partition.
    record snapshot {
        /// Monotonic per-replica revision: advances whenever a local or
        /// synced change is applied. Equal revisions on one replica imply
        /// an unchanged snapshot; revisions are NOT comparable across
        /// replicas.
        revision: u64,
        /// Items in stable (id) order.
        items: list<todo-item>,
    }

    /// The partition this instance serves (the document id). Partition
    /// selection/creation is the framework's concern, not an app's.
    partition: async func() -> result<list<u8>, string>;

    /// Apply any newly synced changes, then report the revision.
    revision: async func() -> result<u64, string>;

    /// Apply any newly synced changes, then snapshot.
    items: async func() -> result<snapshot, string>;

    /// Create a task. Returns its id.
    add: async func(title: string) -> result<string, string>;

    set-completed: async func(id: string, completed: bool) -> result<_, string>;
    set-title: async func(id: string, title: string) -> result<_, string>;
    remove: async func(id: string) -> result<_, string>;
}

world tasks-service {
    export tasks;
}

Deliberately poll-shaped for v0.1 (revision is a cheap probe; items is a full snapshot): the UI can poll revision on a frame-ish cadence and fetch items on change. A change-feed stream is the expected v0.2 once the event plumbing (#16) settles. Served from inside the engine composite (demo-v1 topology decision) — the UI binds this interface and never sees automerge/keyhive/subduction surfaces. An adopted partition that hasn't synced yet reads as revision 0, [], not an error.

G2: content spine is now the real automerge change DAG

Chunk = one automerge change; cref = its ChangeHash; chunk parents = the change's deps() = keyhive pred_refs = sedimentree parents — one DAG across all three layers. Authoring merges the synced frontier first, commits exactly one change, seals under the current epoch. Reading applies in causal order; undecryptable chunks are counted and retried.

Scenario (3 instances over a real relay — Alice's laptop + phone, collaborator Bob, laptop as wire hub): genuine concurrency fork (laptop and phone author from the same frontier) merged by phone's next change — chunk-stats shows a chunk with 2 parents; three-way convergence on the task list; Bob's edit propagates; revocation crypto-excludes Bob while phone rides the rotation in ~100 ms.

Findings (recorded in NOTES + spike README)

1. KeyhiveProtocol's event cache must be refreshed after locally created ops. sync_keyhive serves per-peer event sets from a PeriodicEventCache once one exists; upstream's runtime refreshes it on an interval. Embedders that skip the runtime (us) must refresh_cache() before syncing, or every op created after the cache first fills — e.g. the post-revocation CGKA rotation — is silently never offered to peers (symptom: remaining members fail decrypt with KeyNotFound forever).
2. One-shot bridge syncs need a retry discipline. The spike nudges a refreshed re-sync from read polls that find themselves waiting (missing keyhive doc / undecryptable chunks), rate-limited to ~every 20th poll. The engine proper should run a periodic sync loop like upstream's runtime.
3. The 3b "subscriptions bypass the pull gate post-revocation" observation (Report upstream: subduction subscription push bypasses the pull gate after revocation #17 context) is timing-dependent, not unconditional. With the cache refreshed, the post-revocation ciphertext did not reach the revoked subscriber (0 extra bytes at Bob). Crypto exclusion held in both variants, as designed.
4. Reconfirmed from 3a: create → add members → first seal ordering is load-bearing; members need edit (subduction's put policy) — the spike's kh-add-member takes an access level.

Gap status: G1 done (draft, v0.1), G2 done. Next per the plan: G3 (UI ↔ engine composition) can now build against the WIT above.

[lannbot]

G3 executed and passed — same spike, extended (spikes/tasks-engine/, commit 5df20b0), 8/8 stable runs.

Users are groups of devices (#10's minimal slice)

• "Alice" and "bob" are keyhive groups; devices are enrolled individuals. The partition is delegated to the groups (never to devices); phone and bob decrypt transitively (individual → user group → doc), and subduction's fetch/put policies resolve transitively too (transitive_members — bob's edits pass the put gate through his group chain).
• Enrollment: laptop ingests phone's contact card off the bridge and adds it to Alice's group — done before the partition exists, so the first seal covers the phone (BeeKEM non-retroactivity, now transitive).
• Both demo failure stories, one mechanic at different nodes of the delegation graph:
  • Removed collaborator: revoke bob's group from the doc → bob excluded; notably zero bytes of the next chunk even reached him (push policy filtered a non-member).
  • Lost phone: revoke the phone from Alice's group → docs containing the group drop CGKA leaves for unreachable individuals; the phone still receives ciphertext but decrypt refuses (undecryptable: 1). Laptop (and only laptop) reads everything.
  • Phone rides the bob-revocation rotation in ~100 ms, as before.

Findings (recorded in NOTES + spike README)

1. Cards must be distributed to every member instance; the wire will not do it. The bridge's reachability model offers a group's constitutive ops only to that group's members — in both directions of every pair sync. After Alice pastes bob's card on her laptop, her phone can never learn bob's group over the wire: it holds a doc → bob-group delegation whose delegate never materializes. Partial card distribution failed ~1/3 of runs: the un-carded member wedged permanently at KeyNotFound for the creation chunk (~100 re-sync rounds didn't heal it; op-arrival order varies run to run). Full distribution: 8/8. Product consequence for Identity: devices as leaves, user as signed device list; enrollment ceremony; contact exchange and verification #10: received cards are replicated state — carry them in a doc the user's devices share, not as a one-device paste. (Whether a pending foreign-group delegation should wedge epoch derivation is an open upstream question worth a minimal repro.)
2. Card export is "events for my individual", not "events for the group". static_events_for_agent(group) walks memberships the group can reach upward, excluding its own constitutive ops — exporting for the individual yields the useful card (prekeys + every reachable membership). That also means the card leaks every group/doc the person can reach — a privacy surface to scope before the product exposes it.
3. Both G2 findings held under groups (cache refresh after local ops; nudge-retry discipline). The two revocation flavors show different push behavior (no-bytes vs bytes-but-undecryptable), both safe — more context for the Report upstream: subduction subscription push bypasses the pull gate after revocation #17 draft that the push-bypass is timing/state-dependent, not unconditional.

Gap status

G1 done (draft v0.1) · G2 done · G3 done. The WIT contract is unchanged by G3 (groups are engine-internal; apps still just bind tasks). Next per the plan: G4 (fold the bucket path into the same engine; cold-start from bucket alone), with the G5 persistence decision taken early; G6's deltic inter-task-wakeup check remains the standing rework-risk item.

[lannbot]

G4 executed and passed — same spike, extended again (spikes/tasks-engine/, commit 9e2858c), 6/6 stable runs.

One engine, both sync paths

sedimentree commit (blob = keyhive envelope)
  ├──▶ subduction over component-iroh ──▶ live members
  └──▶ bucket object under a per-epoch name-key ──▶ cold members

The storage spike's stand-ins are replaced by the real coupling, per the gap description:

• Same envelope bytes. Chunk objects are the sedimentree blobs byte-for-byte; BeeKEM is the read gate on both surfaces. No second content encryption; the storage spike's per-epoch content keys are gone.
• Name-key epochs rotate with BeeKEM epochs. store-revoke deletes the member's K_p and pushes a new name-key epoch alongside the CGKA rotation the keyhive revocation causes. Old epochs still grant history names; new objects are dark to old keychains.
• K_p wrapped to keyhive contact-card prekeys. Active::export_prekey_secrets + ShareSecretKey::derive_new_secret_key (static-static x25519); the picked prekeys ride in the K_p object, so no prekey-set agreement between the two sides is needed. The storage spike's ad-hoc x25519 identity is gone.
• The keyhive op stream is stored as per-device name-keyed blobs — everything the flusher's keyhive knows (membership + prekey + CGKA ops, foreign-group ops included: the G3 card lesson applied). This is what makes cold start and offline-invite work from the bucket alone.
• Author flow: bucket-flush = new chunks + oplog + manifest (per-device, Ed25519-signed, entries carry (cref, parents, epoch) so a cold puller feeds its own sedimentree and reuses the causal apply path). Boot flow: bucket-pull = K_p → oplogs → manifests → chunks → apply. Pulls are entirely unsigned GETs; bob holds no bucket credentials.

The cold-start assertion (the demo's "cold device bootstraps from the bucket alone")

A fourth instance — Alice's tablet — never binds and never connects. Enrolled pre-seal via a pasted contact card, it:

1. cold-boots from the bucket (kp epochs=1 events=44 chunks=7) and its view equals laptop's live view;
2. authors through the bucket ('tablet task' → flush → laptop pull → live wire → phone and bob — one DAG, both surfaces);
3. rides the bob revocation via K_p republish (kp epochs=2), reading the post-revocation task;
4. ends the scenario at full 7-task state with iroh conns: 0.

Bob after revocation is dark on both surfaces: no live bytes (as in G3) and kp missing (404) at the bucket — and nothing else in the bucket is locatable from anything he holds.

Findings (recorded in NOTES + spike README)

1. The name-key keychain is doc state, not device state. A device that flushes under a privately minted keychain publishes to names nobody else can derive. bucket-pull adopts the K_p keychain into local state before any flush — the first run failed exactly there (tablet's manifest invisible to laptop).
2. K_p locations are id-derived in this spike (H(doc ‖ owner ‖ member)): no shared secret needed to find the object, payload still prekey-wrapped, revocation deletes it. Cost: K_p existence is probeable from public ids. Production wants a pairwise-secret location, which needs a stable pairwise-DH story over rotating prekeys — flagging as a Storage backends: dumb-store WIT, the cryptographic pull layer, and the S3-compatible provider spike #19/Identity: devices as leaves, user as signed device list; enrollment ceremony; contact exchange and verification #10 design item.
3. Three wit-bindgen runtimes in one composite (0.59 engine + 0.57 fetcher + iroh endpoint) composed with wac plug, zero friction — the storage spike's runtime-isolation pattern scales.
4. The dumb-store contract needed nothing new for the real engine. Remaining Storage backends: dumb-store WIT, the cryptographic pull layer, and the S3-compatible provider spike #19 scope unchanged (R2/B2 quirks, TLS, GC/compaction, credential rotation, Drive provider).

Gap status

G1 ✅ G2 ✅ G3 ✅ G4 ✅. Remaining: G5 (persistence decision — memory-only vs demo-grade extractable vs deltic keystore slice; shapes G6's UX), G6 (the engine's browser leg: deltic wasi:http client host module, the inter-task-wakeup-under-deltic check — the standing rework-risk item — bucket CORS, composite sizing), G7 (choreography/infra). The engine is now demo-complete headless: every demo beat in the target scenario has an executable assertion under wasmtime.

[lannbot]

G5 decided and executed — design record on #11 and in NOTES §Key lifecycle; executable slice in spikes/tasks-engine/ act 10 (commit 08df819), 4/4 runs.

Decision (supersedes the issue's original (a)/(b)/(c) framing, which predated G4): no browser data-persistence layer at all — content rehydrates from the bucket on every boot (the G4 cold path). The only persisted artifact is a sealed identity bundle with LUKS-style keyslots: passphrase+argon2id (the downloadable device file), and a raw-secret slot that the browser leg backs with passkey-PRF (one biometric tap) or a generated recovery phrase. Exposure rule: bucket-replicated copies never carry the passphrase slot. Original option (c) — the keystore slice — remains the honest end-state for the signing key and lands as a swap under the same seam during G6; option (a) is dead; option (b) survives only as the explicit Soft identity variant the bundle requires until the keystore exists.

Proven headless: restart = bundle + bucket, nothing else. Wrong passphrase refused; restored device reads everything AND authors (leaf secrets ride the archive); PRF-shaped slot opens the same bundle. Final scenario state: 8 tasks, one authored by a restarted device, wireless tablet still at iroh conns: 0.

Gap status: G1–G5 ✅. Remaining: G6 (browser leg: deltic wasi:http client host module, the inter-task-wakeup check — still the standing rework-risk item — the passkey-PRF unlock UI, bucket CORS, composite sizing) and G7 (choreography/infra). The demo beats now have headless assertions end to end, including "wipe the device, restore from a file + passphrase."

[lannbot]

G6 scope correction (stale gap text): deltic already ships the browser wasi:http leg — @deltic/wasi/http on repo main (landed with the wasi-0.3-completion work, 2026-08-14): fetch-backed wasi:http@0.3 outbound client (types + client.send), tracking released 0.3.1, à-la-carte because it grants network egress (capability-gated, matching the framework's egress-consent model), with documented fetch divergences (manual redirects, no request trailers, buffered request bodies) — none load-bearing for the S3 path.

G6 remaining, revised:

1. inter-task-wakeup under deltic — still the standing rework-risk item, now the clear first move;
2. compose + size the full browser engine (keyhive + subduction + bridge + automerge + fetcher + iroh endpoint against deltic's webcrypto/websocket/webrtc ports);
3. the passkey-PRF unlock UI (G5's browser leg);
4. bucket CORS recipe.

One integration flag: the spike's fetcher component was built against the wasip3 crate's wasi:http WIT. If that vendors a pre-consolidation 0.3.0-rc-* snapshot, deltic's prerelease resolution is exact-only and the default @0.3 track won't bind — documented fix is a one-line embedder re-key, or rebuild the fetcher against 0.3.1. First composition attempt will surface it.