Real-Time Collaboration  [[3. Resources/Readwise/Full Document Contents/Articles/Real-Time Collaboration|Full Document Contents]] ## Document Notes --- 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:]] - [[#📖 Main Content:]] - [[#🗒️ Notes]] - [[#📖 References:]] - [[#🗣️ Paraphrase:]] - [[#📰 Newsletter:]] - [[#🔗 ✅ Action Items]] - [[#🔗 🧪 Hypotheses]] - [[#🔗 📊 Methodology]] - [[#🔗 ❓ Questions]] - [[#🔗 🔮 Future Research]] - [[#🔗 💡 Implications]] - [[#🔗 🧠 Learning Styles Assessment]] - [[#🔗 📊 Accessibility Assessment]] - [[#🔗 🌍 DEIB Assessment]] - [[#🔗 ✅ Logical validity]] - [[#🔗 🔍 SEO Evaluation]] - [[#🔗 🎯 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 > [!note]+ Document Notes > 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 > <!-- deep-read:sections start --> ## 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 about how your custom blocks should reflect shared selections and presence without adding custom logic. - Community: Join discussions around Phase 3 to help shape editor semantics like undo/redo under concurrency. - New tools: Keep an eye on experiments merging local-first (SQLite) ideas with collaborative editing. Links: - Real-time collaboration proposal on Make Core - Yjs CRDT concepts - WebRTC fundamentals ## ✅ Action Items: Prompt tailored for a GoDaddy Developer Advocate and aspiring OSPO Director: - Purpose: Explain how this article advances open-source advocacy, contributor onboarding, and sustainable governance in WordPress. - Context to include: - Open standards (WebRTC, REST), open libraries (Yjs) as examples of vendor-neutral choices that align with OSPO policy and sustainability. - Contributor engagement opportunities: defining collaboration hooks, presence UI patterns, undo/redo semantics, and transport adapters—ideal entry points for new contributors. - Education: Translate CRDT concepts for PHP/JS devs; create curricula on concurrency, peer presence UX, and offline-first patterns; design workshops on plugin-level transport adapters. - Inclusivity: Emphasize removing infrastructure barriers (works on common hosting), ensuring multi-entity document support, and providing read-only modes and fallbacks. - Governance: Advocate for pluggable architecture, clear ADRs (Architecture Decision Records), and transparent criteria for transport selection, security, and privacy. - Deliverable structure: 1) Executive summary of the proposal in 200 words. 2) Mapping to OSPO pillars: policy, process, tooling, education, community. 3) Contributor pathway: “good first issues” → “advanced” (Yjs integration, adapter design). 4) Education assets: lesson plans for PHP/JS, Git/GitHub workflows for collaborative features, case studies on CRDT. 5) Sustainability and funding: identify long-term maintainers for adapters and conflict-resolution layers; recommend funding for cross-host testing. 6) Transparency: propose a public roadmap and metrics (time-to-resolution for conflicts, latency thresholds, peer count limits). 7) Inclusivity: set UX standards for presence, color contrast, and keyboard navigation; provide read-only and low-bandwidth modes. Use this prompt with each new article to extract alignment, produce teaching materials, and define contributor opportunities. ## 🧪 Hypotheses: - H1: A WebRTC + REST signaling default will allow ≥80% of WordPress sites to enable real-time collaboration without special hosting changes. - H2: Yjs-based CRDTs will reduce merge conflicts and content divergence to near-zero in typical two-to-five-user editing sessions. - H3: Presence and “follow user” features will improve editorial throughput (measured by time-to-publish) by at least 15%. - H4: Adapter-based transports (WebSockets in managed environments) will scale concurrent peers by >3x compared to pure WebRTC in the open web. ### 📊 Methodology: - Data sources: Telemetry from opt-in collaborative sessions (latency, disconnects, merge incidents), revision histories, editor event logs, user surveys, A/B tests on presence UI. - Designs: - Field experiments: Enable collaboration on selected sites; compare publishing efficiency vs. control. - Load testing: Simulate peer counts across network conditions; compare WebRTC vs. WebSockets adapters. - Usability testing: Task-based tests for “follow user,” selection clarity, undo/redo comprehension. - Analysis: Survival analysis for disconnect resilience; mixed-effects models for throughput; error-rate comparison for conflict incidents; qualitative coding of usability feedback. ### ❓ Questions: - How should undo/redo semantics differ when actions are interleaved across users? - What are the privacy implications of broadcasting presence and cursor positions? - Where should CRDT logic live for multi-entity documents and offline-first storage? - How do we gracefully degrade when peer connections fail—what are the UX and data guarantees? - What limits on concurrent peers are acceptable for default WordPress hosting? ### 🔮 Future Research: - Offline-first + CRDT at storage-layer vs. editor-layer tradeoffs (esp. with SQLite). - Security models for read-only vs. write sessions, including per-block permissions. - Heuristics for conflict resolution in complex block hierarchies and patterns. - Cross-site collaboration (multisite, headless) and federation possibilities. - Accessibility-first presence UX and color-safe multi-caret representations. ### 💡 Implications: - Advancing a standards-based, pluggable collaboration stack could set a precedent for open CMS interoperability. - Improved collaboration may reduce reliance on external SaaS tools, keeping content workflows inside WordPress. - Research outcomes can inform policy on privacy, data retention for presence, and revision governance. ### 🧠 Learning Styles Assessment: - Readability: Upper-intermediate technical reading level (approx. Grade 11–12). - Visual (Present): Brief references to an “animated mockup,” but visuals are minimal. Improve by adding sequence diagrams for handshake/auth, CRDT data flow charts, and UI mockups of presence and selections. - Aural (Present): None. Improve with a short audio summary and a podcast segment discussing CRDT choices. - Verbal (Present): Clear technical prose and definitions. Improve with more examples, analogies (e.g., “Google Docs-like” behaviors), and glossary. - Physical/Kinesthetic (Present): None. Improve with interactive demos and code labs (build a transport adapter, simulate conflicts). - Logical (Present): Strong architectural reasoning. Improve with explicit algorithms, state machines, and decision trees for fallbacks. - Social (Present): Mentions collaboration/community. Improve with links to discussion threads, calls for testing, and office hours. - Solitary (Present): Some conceptual depth. Improve by adding reflection prompts and step-by-step setup guides. - Naturalistic (Present): Not applicable. Improve by analogy only if helpful (e.g., “ecosystems” for pluggable architecture). ### 📊 Accessibility Assessment: - Screen Reader Compatibility: Likely standard WordPress.org markup; alt text for the “animated mockup” is referenced but not detailed. Improve by providing descriptive alt text and ARIA labels for presence UI examples. - Keyboard Navigation: Core site is generally accessible, but interactive demos would require tab order and focus management. Improve by specifying keyboard shortcuts for collaborative actions and caret navigation. - Contrast/Readability: Generally good on make.wordpress.org. Ensure examples of presence colors meet WCAG AA contrast and include non-color cues. - Text Resizing: WordPress.org is responsive. Ensure proposed UI mockups scale without overlapping carets/selections. ### 🌍 DEIB (DEIB Assessment): - Cultural Relevance: Neutral/technical. Improve by including examples from diverse contributor contexts (low-bandwidth regions, shared hosting). - Inclusive Language: Generally inclusive and neutral. Improve by minimizing jargon or defining CRDT, WebRTC, signaling, adapters. - Neurodiversity Support: Add clear headings, bullet lists, short paragraphs, and diagrams for complex flows. - Representation: Add inclusive avatars and names in presence examples; consider color-blind-safe palettes. - Psychological Safety: Provide privacy controls for presence visibility and clear consent for sharing cursor/selection data. ### ✅ Logical validity: - Tone: Professional, technical, solution-oriented. - Strong reasoning: - Appeal to open standards: Choosing WebRTC/REST reduces infrastructure barriers. Strength: aligns with WordPress’ broad user base. Improve: Add data on typical host capabilities. - Pluggable architecture: Adapter pattern for transports balances accessibility and scalability. Strength: future-proofing. Improve: Provide interface contracts and stability guarantees. - CRDT selection (Yjs): Evidence from prior Gutenberg explorations. Strength: prior art. Improve: Share benchmarks and edge case analyses for multi-entity docs. - Offline-first consideration: Anticipates real-world connectivity issues. Strength: user-centered. Improve: Specify conflict resolution guarantees during reconnect. - Potential gaps/fallacies: - Hasty generalization risk: Assuming WebRTC + REST will work for “widest possible audience” without empirical data. Mitigation: publish compatibility matrix and telemetry plan. - Appeal to authority risk: Citing library author’s involvement. Mitigation: include independent evaluations and performance tests. - False dilemma avoided: The article offers multiple transport paths, not only WebRTC. - Logical flow: Clear progression from goals → technology → scope → tasks. 🔍 DARVO Analysis Prompt: - Deny: Not present; the piece doesn’t refute allegations or minimize issues. - Attack: Not present; no targeting of individuals/groups. - Reverse Victim and Offender: Not present; no framing of opponents or shifting blame. - Notes: The article is technical and collaborative in tone; no rhetorical manipulation patterns consistent with DARVO. ### 🔍 SEO Evaluation: - Keywords: Present and natural (e.g., “real-time collaboration,” “WordPress block editor,” “WebRTC,” “Yjs,” “CRDT,” “WebSockets,” “offline-first”). - Meta Description: Recommend adding one: “WordPress Phase 3 proposes real-time collaboration in the block editor using WebRTC, Yjs (CRDTs), and a pluggable architecture for scalable, accessible co-editing.” - Title Tag: “Real-Time Collaboration” is concise; consider “Real-Time Collaboration in the WordPress Block Editor (Phase 3).” - Headers: Present; could add H2/H3s for “Architecture,” “Conflict Resolution,” “Scope,” “Error Handling.” - Content Length: Adequate for an announcement; could expand with diagrams and examples for long-form SEO. - Internal Links: Add links to Phase 3 roadmap, Gutenberg repo issues, previous collaboration explorations. - External Links: Include links to Yjs docs and WebRTC specs for authority. - URL: SEO-friendly as-is. - Image Optimization: Ensure alt text for the animated mockup; compress and use descriptive filenames. - Mobile Optimization: WordPress.org is responsive; ensure performance on mobile. - User Engagement: Add calls to action to test, comment, or join a working group. - Schema Markup: Add Article schema; consider FAQ schema for “How will collaboration work?” etc. - Social Sharing: Ensure Open Graph/Twitter Card metadata with a compelling preview image illustrating presence/cursors. ## 🎯 Conclusion: The proposal charts a pragmatic, standards-based roadmap to bring true multiplayer editing to WordPress. By defaulting to WebRTC with REST signaling, adopting Yjs CRDTs for conflict resolution, and offering a pluggable transport architecture, it balances broad accessibility with room to scale. The scope covers UX (presence, selections, follow mode), editor semantics (undo/redo under concurrency), and operational robustness (auth, fallbacks, offline-first). For advocates, educators, and OSPO leaders, it’s a model of open, extensible design that invites contributions across architecture, UI/UX, and documentation—paving the way for a more collaborative, sustainable WordPress ecosystem. You have read it all. However, your current scroll position (38%) indicates you’re partway through the document. <!-- deep-read:sections end --> ## Highlights - Supporting these workflows is not just about concurrency, ([View Highlight](https://read.readwise.io/read/01h5jnqw5b43jsf94h1t0rpc8v)) - Note: The sentence means that helping these group tasks is not only about people working together at the same time, but also about changing the rules that make it hard for people to work together. - 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. ([View Highlight](https://read.readwise.io/read/01h5jns6nh86p2a86tk0d6r7x9)) - Note: Use WebRTC for accessible collaboration in WordPress. - 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. ([View Highlight](https://read.readwise.io/read/01h5jnt5vqbs5mx7kz7mk66fsj)) - Outline the set of hooks necessary to encapsulate collaboration features over block editor providers, like sharing edits and peer state across browsers. ([View Highlight](https://read.readwise.io/read/01h5jp65jr7drb9nym7za52vgk)) - 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. ([View Highlight](https://read.readwise.io/read/01h5jp61sqqhfx0dkqsag52q5a)) - Design and represent “presence” of connected peers in the interface. ([View Highlight](https://read.readwise.io/read/01h5jp5t777cgaq7mr5ytc21nq)) - Lift concurrent editing restrictions. ([View Highlight](https://read.readwise.io/read/01h5jp6ew1jgkkxtzapm0tymbk)) - Review undo / redo stacks and resolution. ([View Highlight](https://read.readwise.io/read/01h5jp6nbbn6y0nfcatnsa0dks)) - 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. ([View Highlight](https://read.readwise.io/read/01h5jp6xf5kcey6q75q9w33w9j)) - Note: If using a special way of working with documents called CRDT, make sure it can work with more than one document at the same time. This is something that they added as a new requirement in Phase 2. - CRDT ([View Highlight](https://read.readwise.io/read/01h5jp7j31ccrcd9tswcrr06zx)) - Note: CRDT (noun): Conflict-free Replicated Data Type, a data structure designed for distributed computing systems that allows for concurrent updates without the need for centralized coordination. 💻🌐 - Employ peer caret and selection primitives that work across block types and design their semantic and visual representation. ([View Highlight](https://read.readwise.io/read/01h5jp8myk5tdfpfsqj9sf4th0)) - Consider offline a first-class use case of collaboration in orchestrating edits and transactions. ([View Highlight](https://read.readwise.io/read/01h5jp8qhmpyx2fmg7dpemhn4w)) - Explore the possibility of “following a user” as they work through a document. ([View Highlight](https://read.readwise.io/read/01h5jp8v96kgbpq94g6bnccp0r)) - Structure WebRTC implementation as an adapter that could be swapped. The architecture should be pluggable so extenders can provide other solutions. ([View Highlight](https://read.readwise.io/read/01h5jq1e4dfgkvtrjpdeymypzm)) - 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. ([View Highlight](https://read.readwise.io/read/01h5jq2rgcg6zqndkkkpfhk01y)) - Note: 1. What are the technical layers involved in real-time collaboration and how do they work together to enable concurrent collaboration and online presence of peers? 2. How does the project plan to address the issue of locking a post when two people try to edit it at the same time, which has been a long-standing restriction in WordPress? 3. How will the use of CRDTs (conflict-free replicated data types) and Yjs library help in establishing conflict resolution primitives and facilitating collaborative editing of block data structures? Question: What is the aim of real-time collaboration? Answer: The primary aim of real-time collaboration is to build functionality into block editors so that concurrent collaboration, shared edits, and online peer presence are possible. Question: What is Yjs and why is it useful? Answer: Yjs is an open-source library that implements conflict-free replicated data types (CRDTs) presented as shared types. It is useful for establishing the primitives for conflict resolution that can reason through block data structures and orchestrate edits over time. Question: Why does the system need to be flexible enough to extend with other server implementations? Answer: The system needs to be flexible enough to extend with other server implementations to scale beyond the current limits for peer-to-peer simultaneous browser connections, or for cases where peer connections cannot be established.