Real-Time Collaboration

Multiple people can work in the same memo at the same time. Canvas keeps everyone’s view consistent in real time, shows you who else is in the document, and resolves the inevitable overlaps without anyone losing work.

Collaborative editing is on by default

New memos are created with collaborative editing enabled . In this mode the editor uses operational transforms (OT) — specifically prosemirror-collab — to merge concurrent edits.

Here’s what that means in practice:

• Two people can type in the same memo simultaneously and both sets of changes are merged into one consistent document.
• Your edits are sent to a central authority as steps (small, ordered change descriptions) over the WebSocket connection. The authority assigns each step a version and broadcasts it to everyone else, who replay it against their copy.
• If your local copy is briefly behind, the editor catches up by pulling the steps you missed — you don’t have to refresh.

You don’t operate any of this directly. You just edit, and Canvas keeps the document in sync. The central authority is a Redis-backed service that arbitrates step ordering atomically, so two simultaneous edits can never corrupt the shared version.

Note

Because collaborative documents synchronize through the step channel, a plain REST “save” of a collab document is rejected with a 409 — the editor sends steps instead of full-document saves. You’ll never hit this in normal use; the editor handles it. The one exception is a superadmin performing an emergency recovery save, which is allowed to override. See Roles and Permissions.

Presence — who else is here

When collaboration is enabled, Canvas shows presence: which collaborators are currently in the memo, and which section each is working in. Presence updates live, so you can see a colleague move into the risk section and know to coordinate.

Presence is heartbeat-based. While you’re active, your client periodically renews your presence; if you close the tab or drop offline, your presence ages out after a short staleness window and you disappear from everyone else’s view. The same heartbeat keeps your live cursor and typing indicators flowing to other collaborators.

How locks behave for collaborative documents

Canvas has a section edit-lock system — pessimistic, one-editor-per-section locking — that predates collaborative editing. For a collaborative document, that hard lock would defeat the whole point of OT (the entire purpose is to let two people edit at once).

So for collaborative documents, the lock service runs in presence-only mode:

• Entering a section marks your editing presence rather than acquiring an exclusive lock.
• Presence never blocks — multiple people can be present in (and editing) the same section at the same time. OT merges their changes.
• The blocking, exclusive-lock behavior is reserved for the non-collaborative fallback path (when collaborative editing is turned off for a document).

In short: with collaboration on, “locks” become soft awareness signals (presence), not gates. You see who’s where; you’re never locked out.

Conflict handling

You generally won’t see conflicts, because OT merges concurrent edits rather than forcing a winner. Two people editing different parts of the memo simply both succeed. Two people editing the same spot have their steps ordered by the authority and transformed so both intents are preserved as far as possible.

Where the non-collaborative (locked) path is in use, Canvas falls back to optimistic locking: a save that would clobber someone else’s concurrent change is rejected with a conflict, and the editor tells you who currently holds the section so you can coordinate rather than overwrite.

Behind the scenes: multi-worker delivery

Canvas is built to run across multiple server workers. When it does, a Redis pub/sub bridge relays WebSocket broadcasts between workers, so a step (or a comment, or a presence update) produced on one worker reaches collaborators connected to a different worker. Self-echo is prevented with a per-worker identifier so a worker doesn’t re-deliver its own messages.

This is infrastructure you never touch — its only job is to make “everyone sees everyone’s changes” hold true regardless of which worker each person’s browser happens to be connected to.

Tip

If your organization ever needs to fall back to the simpler non-collaborative model for a specific memo, an owner can disable collaboration on that document. New memos still default to collaborative editing; the override is per-document. See the owner-only collab controls in Roles and Permissions.

Sources

• src/canvas/config.py — collab_enabled_default = True (Phase C4 rollback lever; new sessions default collaborative)
• src/canvas/services/collab_authority_service.py — Redis-backed OT authority for prosemirror-collab: atomic step accept/reject via Lua, version-ordered step log, canonical doc state for reconnection, periodic compaction
• src/canvas/services/edit_lock_service.py — Phase C4 presence-only mode for collab docs (set_presence/clear_presence/renew_presence, never blocks); pessimistic lock path for the non-collab fallback; optimistic conflict handling
• src/canvas/routes/canvas_routes.py — POST .../save returns 409 for collab-enabled documents unless the caller is a superadmin (emergency override); owner-only collab/enable and collab/disable
• src/canvas/services/redis_pubsub_bridge.py — multi-worker WebSocket relay with per-worker self-echo prevention
• memory/canvas_auth_rbac.md — Redis pub/sub bridge (subscriber/publisher/presence connections), presence heartbeat/staleness window, optimistic locking for edit conflicts
• CLAUDE.md — Canvas collaborative editing (Phase C4): OT default, CollabAuthorityService arbitration, presence-only locks, 409-on-save, rollback lever