Contact
Redline

Collaboration

How live collaboration works from the Redline app's side — rooms, roles, the sync model, and what is built today.

Deferred Collaboration client 1.1

Deferred to 1.1 by decision, not outstanding. The servers are built and tested and the Collaboration panel is the UI seam; nothing in the Redline app dials them, and nothing will before 1.0.

The collaboration servers are built and tested. This page describes the model the client is being built against.

⚠ Server documentation is not published yet: no server ships with the beta, and nothing you install can connect to one. This page is here because it explains what Redline's collaboration features are being built toward, not because you can use them today.

The model#

A collaboration is a room, and a room is scoped either to one document or to a whole project:

doc:<projectId>/<docId>      one document
project:<projectId>          a workspace

The editor dials out over a WebSocket. A webview cannot host a server, but it can open a connection — the same pattern the MCP bridge uses.

There are two ways to host, and the client speaks the same protocol to both:

  • Self-hosted. Connect straight to the host machine. The join code is either the server-wide code or a per-room code the host minted.
  • Amalgative Cloud. Ask the control plane to route the room, which returns a session URL and a ticket; connect to that URL with the ticket.

The sync model#

Markups synchronize by last-writer-wins keyed by markup id, with Lamport timestamps and an author tie-break.

  • One operation per undoable command. The unit of sync is the unit of undo, which is what keeps a collaborative undo comprehensible.
  • Deletes are tombstoned, so a late write cannot resurrect something somebody removed.
  • Layers and page order are whole-value, because they are lists whose meaning is in the ordering rather than in individual elements.
  • Reconnect replays only what you missed, from a bounded operation log, falling back to a full snapshot when the gap is too large.

Lamport timestamps rather than wall-clock time is the detail that matters in practice: two machines with skewed clocks still converge on the same document.

Roles#

RoleCan
OwnerEverything, including membership and roles
RedlineRead and write markups
CommenterRead; comment only
ViewerRead only

Viewer and commenter are enforced at the server — their operations are rejected rather than merely hidden in the UI.

Presence#

Each connected participant publishes a name and a colour. The client shows who is in the room and where they are working.

What you need#

Collaboration is a licensed feature. The free trial is a full local editor and cannot host or join a server; a $50 one-time license unlocks online services, including the right to run the self-hosted server and to connect to the Cloud. Cloud hosting is billed per seat on top. None of it is sold during the beta.

Local version history is a different thing#

Redline keeps a local, single-user, offline version history of a document — snapshots you can compare and roll back to. That is not the same feature as the shared, multi-user project versioning the servers will provide. They share an object model and nothing else, and conflating them is how somebody ends up expecting their offline snapshots to appear for the rest of the team.

Change tracking, layered#

Three mechanisms handle change over time, and each supersedes the last as the source of truth for its scope:

  1. Command-log undo — within a session, for one user.
  2. Version snapshots — across sessions, for one user, offline.
  3. Live sync — across users, in a room.

They are layered deliberately rather than run in parallel. Two mechanisms answering the same question is how two of them come to disagree.