Real-time co-editing: let several people edit an entry at the same time

[khoinguyenpham04]

Problem

Only one person can edit an EmDash entry at a time. Edit locks are on by default and give the first person to open an entry a lease. Everyone else sees the entry read-only, or takes it over and pushes the first person out. The person who was pushed out finds out on their next heartbeat, up to two minutes later.

When locks are off, or when one person has the entry open in two tabs, saves are guarded by a revision token. A save based on an older version is rejected, and the editor can either reload or save anyway, which replaces the newer version. Nothing is merged.

Teams expect to work on a draft together, the way they do in Google Docs or Notion. A writer and an editor want to fix the same post at once, and a team wants to finish a launch page together before a deadline. Today they take turns, or draft somewhere else and paste the result in.

Use case

This affects any site where more than one person works on the same entry at the same time:

• a newsroom tightening a story before it goes out;
• a marketing team finishing a launch page;
• an agency and its client polishing copy together;
• a docs team fixing a page during an incident.

The expected interaction is the one people know from Google Docs:

• Presence. Everyone with the entry open sees who else is there, which field they are in, and their cursor in the text.
• Merging. Edits from everyone appear within a second and merge, even in the same paragraph.
• Undo. Undo reverses only your own changes.
• Connection. Losing the connection does not lose work, and the editor shows when changes have not reached the server yet.
• Publishing. Publishing stays a single, deliberate step taken by someone with permission to publish.

The scope I have in mind for an RFC:

• Co-editing the whole entry form in the admin editor, including Portable Text fields, for collections with drafts and revisions.
• Presence: avatars for everyone in the entry, field highlights, and named cursors in rich text. People without edit permission can watch changes live but cannot edit.
• The server owns each editing session. It checks permissions on every change and stores each change before sharing it. It saves the shared draft as ordinary revisions, so hooks, validation and revision history keep working.
• No writes around a live session. While people have the entry open, REST and MCP writes keep today's behaviour and get ENTRY_LOCKED. Plugin writes, scheduled publishing and the visual editing toolbar must not overwrite live edits.
• Cloudflare Workers and Node, with no third-party service. Where a session cannot be hosted, and on collections without revisions, today's edit lock stays as it is.
• Out of scope for the first version:
  • AI agents editing alongside people;
  • editorial comments (Editorial comments on entries #4054);
  • suggested edits or tracked changes;
  • offline editing beyond short disconnections;
  • co-editing from the visual editing toolbar;
  • Node deployments that run several processes.

Feedback that would help shape the RFC:

• How many people typically work on the same entry at the same time on your site?
• Do you need to edit the same field together, or is it mostly different fields of one entry?
• Should real-time editing be on by default for new sites, or something you switch on per collection?
• How long do your editors need to keep working while offline?
• While people are editing, should agents and integrations keep waiting, as they do today, or join the session in a later version?
• Do you run EmDash on Node with more than one process?

Current workarounds

Current workarounds

• Take turns, using the edit lock and Take over. The person who is pushed out only finds out on their next heartbeat, up to two minutes later.
• Turn edit locks off and rely on the conflict notice. The second person to save has to choose between their version and the newer one, and one set of changes is lost.
• Draft in Google Docs or Notion and paste the result into EmDash. This loses Portable Text structure, embeds and custom blocks, and the copy drifts from the entry.
• A plugin cannot cover this. It needs changes to the editor, the save path and how the server handles connections.

Your involvement

• I am requesting this capability.
• I am offering to champion the design in a feature plan or RFC.
• I am offering to implement it after the design is accepted.

[reducedhackers]

I can think of a conversation a client brought up when using oasis-workflow to handle edits and authoring ; so there is a recent relevant here in this discussion . Their question is worth considering , though I note that in the discussion post already defined that publishing is a single step.

The question asked by the client was ; when more than one person edits at any time, who is responsible for publishing ?
A) the Original Content creator ?
B) the last person to make an edit ?
C) both/many/any editors have to agree to publish

In terms of revisions, merges .. a multiplayer edit experience would benefit a few clients though it would be important to ensure that there is clarity when people are "done with their work" which is why the question of "who published" comes up.

Im giving this discussion a +1 from me

[github-actions[bot]]

Design PR #4267 proposes proposals/real-time-co-editing.md for this Idea. Review of the design continues on the pull request.