Standard y-websocket baseline
Use the documented provider/server arrangement to establish client behavior before replacing the backend. This is a control experiment, not evidence about Durable Objects.
Composition · realtime systems / RESEARCH IN PROGRESS
Can a Lexical editor collaborate through Yjs on Durable Objects?
The component capabilities are documented. Provider compatibility and durable recovery are still unresolved integration work.
A scoped answer, with choices.
- Two authenticated users edit one rich-text document.
- Edits must survive a backend restart; reconnect must recover missed updates.
- Do not assume a generic WebSocket server implements the Yjs provider protocol.
Custom Durable Object adapter
Potential room-local coordination, but protocol handling, persistence and authorization remain work to implement and verify.
Claims you can inspect.
Lexical documents React collaboration bindings built on Yjs.
React integration in current upstream documentation.
Source: Lexical React collaboration
Getting started; Initial editor content · Checked 2026-09-14
Living documentation; runtime versions not pinned
Inspect original source ↗Lexical identifies y-websocket as its officially supported connection provider.
This does not establish compatibility with a custom Durable Object server.
Source: Lexical React collaboration
Getting started; Initial editor content · Checked 2026-09-14
Living documentation; runtime versions not pinned
Inspect original source ↗The y-websocket client accepts an awareness instance and exposes connection and synchronization state.
Client provider API; no tested server implementation selected.
Source: Yjs WebSocket provider
Client API · Checked 2026-09-14
Living documentation; runtime versions not pinned
Inspect original source ↗Durable Objects can keep WebSocket clients connected during hibernation while resetting in-memory state.
Hibernation API; an in-memory Y.Doc is not a persistence strategy.
Source: Durable Object WebSockets
How hibernation works · Checked 2026-09-14
Living documentation; runtime versions not pinned
Inspect original source ↗Probe a Durable Object collaboration adapter
This is a procedure draft, not a working implementation. Package versions and executable artifacts are not yet pinned.
Establish the baseline
Pin Lexical, Yjs and y-websocket versions. Start the upstream collaboration example in two independent browsers; retain the lockfile and configuration.
Expected: A repeatable baseline environment is recorded.
Select the room adapter
Document the exact client/server message contract and authentication boundary. Do not substitute an echo server. This prerequisite is unresolved.
Expected: A pinned adapter and protocol fixtures exist before proceeding.
Specify durable recovery
Define persisted updates, snapshot recovery, and acknowledgement semantics. Separate hibernation from process restart checks.
Expected: A recovery design with an explicit durable-write boundary.
Run the acceptance matrix
Capture convergence, reconnect, restart and unauthorized-room results with sanitized logs and versions.
Expected: Each check has an observed result or explicit not-attempted state.
What would count as evidence?
Not attempted
Concurrent edits converge to identical document state.
Not attempted
A disconnected client recovers missed edits after reconnect.
Not attempted
Edits acknowledged as durable survive the specified backend restart.
Not attempted
An unauthorized client cannot read or write the room.
Resolve before calling this a recipe that works
- Select and pin a compatible server adapter or implement its protocol.
- Specify when a received edit becomes durable and how state is reconstructed.
- Define room authorization, revocation, and server-side initialization.