Sheetwrite
GitHub

CAPABILITY / LIVE COLLABORATION

Two clients, one shared history, no lost updates.

Two live clients against one sequencing server: ordered durable commits, duplicate acknowledgements, presence, offline queues that drain on reconnect, version-gap buffering, and conservative conflict recovery.

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

LoadingStarting the in-page server…

Reconnect drillOne offline edit, one ordered resolution
Anaonline

LatestNo sync events yet.

Version
v0
Queue
0
Grid 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
Grid 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 and watch both clients converge.

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.

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.