How Rustpad Supports Real-Time Collaboration

Updated

Rustpad supports real-time collaboration by running a shared document session on its server and using operational transformation (OT) to merge edits from multiple users. Each participant's changes are sent to the server, transformed against other pending edits, and broadcast so every client converges on the same text. This design is what allows several people to type in the same document at once without overwriting each other's work.

The shared document session

When multiple users open the same Rustpad document, they join a single shared session rather than working on private copies. The server holds the authoritative document state for that session and acts as the coordination point:

  • Clients send operations, not whole documents. Each edit is described as an operation (for example, "insert these characters at this position" or "delete this range").
  • The server orders incoming operations. Edits arrive from different users at different times, so the server establishes a sequence for them.
  • The server broadcasts results. Once an operation is accepted, it is sent to the other connected clients so their views update.

Because everyone is attached to the same session, there is one source of truth for the document at any moment.

How concurrent edits are merged

The hard problem in simultaneous editing is that two users can act on the same region at the same time. If one person inserts a word at the start of a paragraph while another deletes a sentence later in that paragraph, applying both edits naively against stale positions would corrupt the text.

Operational transformation addresses this by transforming an incoming operation against the operations that were already applied but that the sender had not yet seen. The transformed operation is then applied to the current document state. In practice:

  1. User A and User B both start from the same document version.
  2. User A inserts text; the server applies it and broadcasts it.
  3. User B, still on the older version, sends a delete whose position was computed before A's insert.
  4. The server transforms B's delete so its position accounts for A's inserted characters, then applies it.
  5. Both clients end up with the same text.

The key property is convergence: regardless of the order in which operations reach the server, all clients that have received the same set of operations display the same document. Users see each other's changes appear as they happen, and no one's edit is silently dropped.

A concrete example

Suppose the document reads hello world. User A places the cursor after hello and types ,; User B simultaneously selects world and deletes it. Both operations are based on the original text. The server applies A's insert first, giving hello, world. When B's delete arrives, it is transformed to target the shifted range, so the result is hello, rather than a mangled string. Both users converge on hello,.

Why this matters for simultaneous editing

OT is what makes the collaboration feel natural rather than lock-based:

  • No locking or turn-taking. Users do not need to claim a section or wait for others to finish; edits are merged as they arrive.
  • Low conflict cost. Overlapping edits are resolved by transformation rules instead of prompting users to reconcile versions manually.
  • Consistent shared state. Everyone in the session sees the same document, which is essential for a collaborative editor.

The trade-off is that correctness depends on the transformation logic and on the server maintaining a consistent operation order. That is why the server, not the clients, is the coordination point for the session.

What this means in practice

For a team using Rustpad, the collaboration model is straightforward: share the document, and everyone edits the same live text. There is no separate "merge" step and no need to pass files back and forth. If you are evaluating Rustpad for a use case, the relevant questions are whether a single shared session fits your workflow and whether your edits are primarily text-level, which is the case OT is designed for. For workflows that require offline editing with later synchronization, or heavy structural changes such as moving large blocks, check how the tool behaves in those scenarios before relying on it.