Real-Time Collaboration ![rw-book-cover](https://make.wordpress.org/core/files/2023/07/collab-concept.gif) ## Metadata - Author: [[Make WordPress Core]] - Full Title: Real-Time Collaboration - Category: #articles - Document Note: --- tags: - #wordpress - #gutenberg - #realtime-collaboration Author: Make WordPress Core Source: Make WordPress Core blog Reference: https://make.wordpress.org/core/2023/07/03/real-time-collaboration/ date created: 2025-08-22 00:00 --- # Title: Real-Time Collaboration in the WordPress Block Editor (Phase 3) — Goals, Scope, and Technical Approach ## Table of Contents: - 🔗 [📝 Summary](#-summary) - 🔗 [📖 Main Content](#-main-content) - 🔗 [🗒️ Notes](#-notes) - 🔗 [📖 References](#-references) - 🔗 [🗣️ Paraphrase](#-paraphrase) - 🔗 [📰 Newsletter](#-newsletter) - 🔗 [✅ Action Items](#-action-items) - 🔗 [🧪 Hypotheses](#-hypotheses) - 🔗 [📊 Methodology](#-methodology) - 🔗 [❓ Questions](#-questions) - 🔗 [🔮 Future Research](#-future-research) - 🔗 [💡 Implications](#-implications) - 🔗 [🧠 Learning Styles Assessment](#-learning-styles-assessment) - 🔗 [📊 Accessibility Assessment](#-accessibility-assessment) - 🔗 [🌍 DEIB Assessment](#-deib-deib-assessment) - 🔗 [✅ Logical validity](#-logical-validity) - 🔗 [🔍 SEO Evaluation](#-seo-evaluation) - 🔗 [🎯 Conclusion](#-conclusion) ### References: - Make WordPress Core. “Real-Time Collaboration.” https://make.wordpress.org/core/2023/07/03/real-time-collaboration/ ## 📝 Summary: This article outlines the vision and foundational architecture for bringing real-time collaboration to the WordPress block editor as part of Phase 3. It proposes enabling concurrent editing, presence, and shared selections without specialized server requirements by using open web standards (notably WebRTC), a scalable signaling layer over REST, and a pluggable architecture for advanced setups (e.g., WebSockets). For conflict resolution across block and multi-entity documents, it suggests using CRDTs via Yjs, with attention to offline-first workflows and SQLite explorations. The scope includes lifting post-edit locks, designing presence/cursor affordances, adapting undo/redo, supporting selection primitives, defining authentication/messaging semantics, and ensuring adapters for transport can be swapped. Key quotes: - “The primary aim of real-time collaboration is to build functionality into the block editors so that concurrent collaboration, shared edits, and online presence of peers are possible.” - “This likely puts us on the path of building on top of open web standards like WebRTC… WordPress itself could provide an easy to scale signalling server, likely over REST endpoints, for authentication handshake.” ## 📖 Main Content: The article frames real-time collaboration as a core capability of the WordPress block editor, removing historical constraints like single-user editing locks. It emphasizes: - Broad accessibility: Use standards that don’t require complex hosting; default to WebRTC for peer-to-peer sessions with REST-based signaling. - Extensibility: Provide a pluggable adapter layer so hosts or plugins can swap in WebSockets or other transports to scale beyond browser peer limits or restricted networks. - Conflict resolution: Adopt CRDTs, specifically Yjs shared types, to reconcile concurrent edits in block data and plan for multi-entity documents and offline-first needs. This aligns with broader SQLite explorations for local-first approaches. - UX for collaboration: Introduce presence (avatars, names), peer carets, shared selections integrated into UI (e.g., block list), and consider a “follow a user” mode. - Editorial integrity: Revisit undo/redo semantics to make them collaboration-aware; ensure saving, revisions, and per-user/device conflict handling work even when connections drop. - Security and auth: Define handshake semantics, read-only modes, and fallback paths when peer connections can’t be established. The scope section lists concrete tasks like: reviewing prior explorations, defining block-editor hooks for collaboration, ensuring no block author changes are needed, lifting concurrent editing restrictions, and handling error scenarios with offline-first parity. ### 🗒️ Notes - Vision and Goals - Concurrent editing, shared edits, online presence in the block editor. - Remove legacy “post locking” so multiple users can truly co-edit. - Keep collaboration accessible to most WordPress sites without exotic infrastructure. - Architecture and Transport - Default to WebRTC with a REST-based signaling server for handshakes and auth. - Provide a pluggable adapter; allow WebSockets/other transports for scale or restricted environments. - Consider read-only sessions and fallback paths when peer connections fail. - Conflict Resolution and Data Model - Use Yjs (CRDTs) for conflict-free shared editing of block-based content. - Extend to multi-entity documents (a newer Phase 2+ requirement). - Explore SQLite/offline-first approaches that may require different abstraction layers for CRDT handling. - UX and Presence - Peer presence UI: carets, selections, avatars/names. - Integrate selection state with the block list sidebar. - Explore “follow a user” behavior to assist reviews/training. - Editor Semantics - Rework undo/redo stacks for collaborative correctness. - Orchestrate edits and transactions during disconnects or multi-device same-user sessions. - Handle saving and revision allocation robustly under concurrency. - Scope Checklist (high-level) - Review prior experiments and tradeoffs. - Define block editor hooks for collaboration. - Ensure block API compatibility without author changes. - Lift concurrent editing restrictions (remove post lock limitation). - Design presence UI and selection semantics. - Adapt undo/redo. - Ensure CRDTs work with multi-entity docs. - Prioritize offline-first behaviors. - Define authentication, messaging, error scenarios, and pluggable transport adapters. ## 📖 References: - Real-Time Collaboration (Make WordPress Core): https://make.wordpress.org/core/2023/07/03/real-time-collaboration/ - Yjs (CRDT library) overview: https://yjs.dev/ - WebRTC overview: https://webrtc.org/ - REST API in WordPress: https://developer.wordpress.org/rest-api/ ## 🗣️ Paraphrase: 1) Original idea: “The primary aim ... is to build functionality into the block editors so that concurrent collaboration, shared edits, and online presence of peers are possible… using technologies that don’t rely on sophisticated server setups… likely WebRTC with a REST signaling server.” Paraphrase: The goal is to enable genuine multi-user editing in the block editor—live co-authoring, shared changes, and visible presence—implemented with standard web tech that runs on typical WordPress hosting. A practical path is peer-to-peer connections via WebRTC, coordinated by a WordPress-provided signaling service over REST for authentication and session setup. 2) Original idea: “Outside of the peer sharing setup, we also need to establish the primitives for conflict resolution… likely Yjs… CRDTs… has worked with block data, but not yet with multi-entity documents… offline-first experiences may need CRDT at a different layer.” Paraphrase: Beyond peer connectivity, the system needs robust reconciliation of simultaneous edits. Yjs, a CRDT-based library, is a strong candidate, proven with block data but not yet in complex multi-entity documents. As offline and local-first patterns mature (e.g., SQLite), conflict management may need to operate at a different level of the stack. ## 📰 Newsletter: This week in WordPress: We’re inching closer to truly multiplayer editing in the block editor. The Core team’s real-time collaboration plan prioritizes broad accessibility—think WebRTC for peer-to-peer sessions with a lightweight REST-based signaling layer—so most sites can co-edit without exotic servers. For reconciling edits, they’re leaning on Yjs (CRDTs) to keep blocks in sync even when folks go offline or work across devices. Expect presence UI, shared selections, and a “follow a user” mode to make pair-writing and review a breeze. Bonus: The architecture is pluggable, so power users can swap in WebSockets to scale collaboration further. Curious? Dive into the proposal at Real-Time Collaboration on Make Core. - Learn: Brush up on CRDTs with the Yjs docs for a sneak peek at conflict resolution. - Build: Start thinking - Document Tags: [[gutenberg]] [[phase 3]] [[wordpress]] - Summary: Real-time collaboration is an important part of the Phase 3: Collaboration roadmap for WordPress. The goal is to enable concurrent collaboration, shared edits, and online presence of peers in the block editor. The functionality aims to remove restrictions in WordPress, such as locking a post when multiple users try to edit at the same time. The implementation will use open web standards like WebRTC for wide accessibility and scalability. Other tasks include conflict resolution, integration with block data structures, and exploring offline-first experiences. The project welcomes feedback and involvement from interested parties. - URL: https://make.wordpress.org/core/2023/07/03/real-time-collaboration/ This is part of the **Phase 3: Collaboration** roadmap. The main projects are [Real-Time Collaboration](https://make.wordpress.org/core/2023/07/03/real-time-collaboration/), [Workflows](https://make.wordpress.org/core/2023/07/04/workflows/), [Revisions](https://make.wordpress.org/core/2023/07/05/revisions/), [Media Library](https://make.wordpress.org/core/2023/07/07/media-library/), [Block Library](https://make.wordpress.org/core/2023/07/10/block-library/), and [Admin Design](https://make.wordpress.org/core/2023/07/12/admin-design/). #### Introduction The primary aim of real-time collaboration is to build functionality into the block editors so that concurrent collaboration, shared edits, and online presence of peers are possible. Supporting these workflows is not just about concurrency, though, but also about lifting restrictions that have been present in WordPress for a long time, such as locking a post when two people try to edit at the same time. There are various technical layers underpinning this functionality, so let’s quickly recap what they are and what we need to take into account to get started. [![Animated mockup showing multiple users moving their cursors on a shared editor screen.](https://make.wordpress.org/core/files/2023/07/collab-concept.gif)](https://make.wordpress.org/core/files/2023/07/collab-concept.gif) First, these capabilities should be available to the widest possible audience. That means using technologies that don’t rely on sophisticated server setups that would restrict the ability for people to collaborate within their WordPress sites, regardless of hosting infrastructure. This likely puts us on the path of building on top of open web standards like [WebRTC](https://webrtc.org) where we can ensure deployment of these features without any special burdens on the backend. WordPress itself could provide an easy to scale signalling server, likely over REST endpoints, for authentication handshake. However, we also want to ensure the system is flexible enough to extend with other server implementations for more advanced needs — such as a WebSockets service — in order to scale beyond current limits for peer-to-peer simultaneous browser connections, or for cases where peer connections cannot be established. This would naturally be plugin territory. Outside of the peer sharing setup, we also need to establish the primitives for conflict resolution that are going to be able to reason through our block data structures and orchestrate edits over time. For this purpose, it’s likely [Yjs](https://github.com/yjs/yjs) will come in handy, which is an amazing open source library that implements *conflict-free replicated data types* (aka [CRDTs](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type)) presented as shared types. This library has already been put to good success in most of the past explorations within [the Gutenberg repo](https://github.com/WordPress/gutenberg/pull/23129) and [related projects](https://github.com/youknowriad/asblocks). The author of the library has also engaged directly in some of these iterations with suggestions and feedback. While it has worked pretty well with block data, it has not been paired with multi-entity documents yet. Furthermore, ongoing SQLite explorations might uncover other ideas and opportunities for wider offline-first experiences where CRDT needs to be handled at a different abstraction layer. #### Scope This is a summary of the broad tasks we need to look into: * [Review all current explorations](https://github.com/WordPress/gutenberg/issues/1930), their lessons and tradeoffs. * Outline the set of hooks necessary to encapsulate collaboration features over block editor providers, like sharing edits and peer state across browsers. * Ensure capabilities build on top of the block API so that block authors don’t need to make modifications for their blocks to work in collaborative environments. * Design and represent “presence” of connected peers in the interface. Integrate selection state with other useful parts of the interface, like the block list sidebar. * Lift concurrent editing restrictions. Right now WordPress locks a post to the current user that is editing it. Another user can take over, but it doesn’t allow two users working on the same post at the same time. * Review undo / redo stacks and resolution. It’s likely some modifications are needed here. * If employing CRDT, ensure its designed to work with multi-entity documents, which is a newer requirement from Phase 2 compared to just Phase 1. * Employ peer caret and selection primitives that work across block types and design their semantic and visual representation. * Consider offline a first-class use case of collaboration in orchestrating edits and transactions. * Explore the possibility of “following a user” as they work through a document. * Define authentication and messaging semantics. For example, the characteristics of a WebRTC handshake with a plain HTTP REST API request to the backend. Provide answers to questions like read only sessions over peer-to-peer connections and cases where peer-connections cannot be established. * Structure WebRTC implementation as an adapter that could be swapped. The architecture should be pluggable so extenders can provide other solutions. * Outline error scenarios and functional overlaps with offline-first capabilities. For example, peers losing a connection while still making edits. We’d want to employ this for same-user resolution should you be editing across different devices as a single user. Handle saving and revision allocation. #### Get involved! If you are interested in the challenges of real time collaboration or want to leave any feedback on the project, please chime in., Real-Time Collaboration, Make WordPress Core, 01h5jms6gp7wn4mrz5055wthnk.