As real-time collaboration is being developed for possible inclusion in WordPress 7.0, a critical architectural decision remains unresolved: what should be the default transport layer shipped in Core? This issue is meant to centralize the conversation and decision on this in a shared place as I'm starting to see it pop up in various places.

Background context

Real-time collaboration aims to bring Google Docs-style simultaneous editing to WordPress, powered by Yjs (a CRDT framework). The architecture to do this breaks down into three components:

• Interface: Avatars, presence indicators, UI elements
• Engine: Yjs-based sync that records and merges changes
• Transport: How data synchronizes between collaborators

The Interface and Engine will ship in Core. But what should the default Transport be, especially as WordPress runs on everything from basic shared hosting to enterprise infrastructure? Ultimately, the default transport needs to work reliably across this entire spectrum while still providing a meaningful collaborative experience.

The Problem

As outlined by @youknowriad in the original architecture post:

"The most performant transport layers rely on a centralized WebSocket server and a lot of PHP hosting providers don't have support for restful communication using web sockets. This means that we need an alternative communication layer that can work with any WordPress install by default while allowing the communication layer to be replaceable by plugins/hosts."

And as @matveb noted in the Real-Time Collaboration vision:

Capabilities "should be available to the widest possible audience," using "technologies that don't rely on sophisticated server setups."

Various options

A range of options have been discussed and explored, from WordPress VIP using WebSockets to @dmonad exploring HTTP requests for syncing. This isn't wholly comprehensive but here's what I've seen discussed: