CURSORS / LIVE PIPELINING

Cap'n Web is the fast conversation, not the memory.

Cursors needs both durable history and fast live execution. Those are different jobs.

signed cursor / continuation ↓ choose a capable body ↓ Cap'n Web pipeline ↓ perform bounded work ↓ receipt + successor cursor

Why it fits

Cap'n Web is browser-native object-capability RPC with HTTP batching, WebSocket sessions, MessagePort support, streaming, and promise pipelining. A later call can depend on an earlier result without waiting for another network round trip.

Good fit: append → receipt read-back in one batch after a local outbox commit.
Bad fit: replacing cursor history, capability signatures, SQLite state, torrents, or offline recovery with an RPC session.

HTTP remains the boring baseline

If WebRTC is unavailable, the browser can still send a batch to one Cursors RPC endpoint. Several dependent fabric operations may complete in one request instead of degenerating into sequential REST calls.

HTTP batch mailbox(handle).append(envelope, signed proof) ↓ mailbox(handle).receipt(append.id, signed proof)

Across many cursors

A scheduler can pipeline placement and resume work for several ready cursors while keeping each returned body/mailbox/store object capability-scoped. Losing the live session must still leave enough checkpoint/mailbox state for another body to continue.

And SQLite?

Keep SQL local. Browser SQLite lives in one writable Worker per page using the official SQLite WASM backend registry, with local databases composed by ATTACH. Cap'n Web can talk to that Worker through MessagePort and to remote fabric bodies through HTTP/WebSocket. It moves bounded semantic mailbox operations, not remote SQL statements, WAL, or SQLite pages.

The local Worker commits cursor intent and its outbox row first. Remote effects reuse short-lived Cursors-Envelope proofs and the existing CloudMailbox identity, replay, friend/stranger, and quota checks. Production and the ordinary PR preview keep writes disabled; a separate route-free curso-rs-capnweb-preview Worker owns the opt-in test namespaces.

Read-only fetched snapshots are a separate experiment. The range-fetch ideas in sql.js-httpvfs, wa-sqlite, and newer official-WASM HTTP VFS work will be measured against a hash-verifying curso-range adapter before any fastest-backend claim.

Run the HTTP-batch and local SQLite Worker demo →

TLV status

The TIP-inspired island code is now explicitly experimental. It may prove useful for native/embedded framing later, but it is not the Cursors wire contract. We will compare it against compressed Cap'n Web, canonical CURSO records, and direct SQLite rows before promoting anything.

See SQLite, JS/WASM VFS, and Cursor State and CURSO/0 Wire Profile.