Sheetwrite
GitHub

CAPABILITY / LIVE COLLABORATION

Two clients, one shared history, no lost updates.

Two live clients share one sequencing server. Watch ordered commits, presence, offline edits that drain on reconnect, and safe conflict recovery.

Clients
Two, fully isolated
Ordering
Server-sequenced versions
Durability
IndexedDB pending queues
Conflicts
Conservative rebase

Two clients · one sequencing server

Two analysts. One shared forecast.

LoadingStarting the in-page server…

Six seconds of concurrent edits, dropped connections, and reordered broadcasts.
Ana's forecastCatching up
–

Client version v0

Bram's forecastCatching up
–

Client version v0

Server headv0Waiting for clients
Anaonline

LatestNo sync events yet.

Version
v0
Queue
0
Forecast total
–
Presence
  • No one yet
Sequencing lanev0
initial

Start with a disconnect

Take Bram offline. His Grid remains editable.

Server decisions

  1. Waiting for the first commit.
Bramonline

LatestNo sync events yet.

Version
v0
Queue
0
Forecast total
–
Presence
  • No one yet
Advanced protocol faults

Ana · transport faults

  1. Sync events appear here.

Bram · transport faults

  1. Sync events appear here.

Server and recovery

Demo-onlyThis in-page sequencer makes the real PersistenceAdapter + RemoteOperationSource boundary observable. Your backend supplies that transport and durable store.

Try itUse the sequencing lane: take Bram offline, queue one real Grid edit, then reconnect. Then clear 100,000 usage cells on Ana's client and undo them: Bram applies the batch in one transaction.

VERIFIED IN THIS SCENARIO

Every behavior above is the public contract.

  1. Convergence under ordering

    Every commit is sequenced once by the server and fanned out; both grids — including live formulas — converge to identical state.

  2. Loss without double-apply

    Drop an acknowledgement, retry with the same mutation id, and the server answers duplicate: applied exactly once, at the original version.

  3. Offline is a first-class state

    An offline client keeps committing into its durable IndexedDB queue; reconnecting drains the queue in order through the same synchronization flow.

  4. Gaps and conflicts stay explicit

    Out-of-order broadcasts buffer until the gap closes; stale base versions surface as conflicts that recover through the documented rebase loop.

  5. Atomic multi-version batches

    A restore that is larger than one server version (0.5.0) becomes one atomic batch: the server stores every version or none, and the peer applies the whole batch in a single transaction.

OWNERSHIP BOUNDARY

What Sheetwrite provides — and what your host owns.

Everything moving on this page is the real collaboration flow running in your browser tab. The server is deliberately illustrative — the responsibilities below never move into Sheetwrite.

Sheetwriteships in the library
  • Commit ordering

    SyncCoordinator: optimistic local commits, ordered acknowledgements, echo deduplication, gap buffering, and fail-closed input limits.

  • Presence & conservative rebase

    PresenceCoordinator shares ephemeral selections; rebaseDocumentOperations transforms safe edits and reports explicit conflicts instead of guessing.

PersistenceAdapter + RemoteOperationSource

Your hostyou implement and deploy
  • Transport

    The in-page server here stands in for your WebSocket or realtime channel. Sheetwrite defines the messages and ordering rules, but ships no network code.

  • Durable server storage

    Server-side document state, revision history, and backups live in your database behind your PersistenceAdapter implementation.

  • Auth, authorization & deployment

    Who a collaborator is, what they may edit, and where the service runs are host decisions — presence identity is advisory UI state, never access control.