Collaborative editor - two carets in one paragraph

Ask these before drawing anything

• Must an edit appear instantly on the machine that made it? If yes - and it is always yes - then every client is already divergent and the whole board is about reconciling, not about preventing.
• How many people may edit one document at once? Two is a different system from two hundred, and two hundred is mostly a presence problem rather than an editing one.
• Is the document plain text, rich text, or a tree with attributes? OT on a flat string is a well-understood ninety lines; OT on a tree with formatting spans is where implementations go to die.
• Must edits made offline be accepted, or may they be refused? "Accepted" means keeping enough history to transform them forward, which sets the op log retention, which sets the storage bill.
• Does the product need per-character attribution - who typed this word? That is a different data structure from "who changed this document", and asking for it later is a rewrite.
• How long is a document expected to live? A CRDT accumulates metadata per character that survives deletion, so a five-year document is a different size from a five-day one.
• Is there a server at all? Peer-to-peer or local-first removes the ordering authority and forces a CRDT. Saying "we have a server" is the decision that makes OT available.
• What is the largest document anyone may open? There is always a limit and it is always found by a user rather than written down.

Functional

• Two or more people edit one document simultaneously and every one of them converges on the same text.
• An edit appears on the machine that made it before any network round trip.
• Each participant sees the others’ carets and selections, labelled and coloured stably.
• An edit made while disconnected is not lost: on reconnect it is transformed onto the current head and applied.
• A document can be reverted to any earlier point for as long as the op log retains it.
• A view-only participant sees live changes and cannot send any.

Non-functional

• Local echo: under 16 ms, which is one frame. This is not negotiable and it is why local-first is a requirement, not a design.
• Remote application: p50 under 120 ms, p99 under 400 ms, same region.
• Convergence: after any sequence of concurrent edits and any delivery order, all replicas that have seen the same set of ops hold the same document. This is a correctness property, not a latency one.
• 99.95% availability for opening and editing. Presence has no availability target at all.
• Durability: an acknowledged edit survives a clean shutdown. An acknowledged edit does NOT currently survive a hard kill of the process holding the room, and that gap is stated rather than hidden.

Out of scope

• Comments and suggestions, which anchor to ranges that move and are their own board.
• Offline-first mobile with multi-day divergence.
• End-to-end encryption, which removes the server’s ability to transform and therefore forces a CRDT.