Collaboration is a document model, not a meeting mode
Real-time screenplay collaboration is often presented as a special session: one person hosts, other writers join, and the shared state exists only while the room is open. Laper instead treats synchronization as part of the project document itself.
Each project has a Loro document containing the screenplay and related project data. The browser's main thread owns the Loro document and the React projection. A worker handles byte-oriented persistence and WebSocket traffic. A dedicated lorosync service exchanges updates with the server. The editor, scene views, character data, beats, and other project dimensions therefore participate in one synchronization model.
The result is a writers' room that does not have to nominate a separate “real file” after every session.
The actual synchronization path
keyboard or tool edit
→ Plate operation
→ screenplay node update in Loro
→ worker persistence and pending-update log
→ lorosync WebSocket
→ collaborators' Loro documents
→ React and editor projections
The worker does not parse the screenplay or own a second document. It moves bytes, persists updates, and manages connection state. This keeps domain logic on one main-thread Loro document while taking IndexedDB and network I/O off the editing path.
Laper also separates Supabase Realtime from CRDT synchronization. Realtime is reserved for a small set of project-scoped signals such as the current user's AI tasks, credit balance, and presence. It does not carry screenplay content and never writes CRDT state. The screenplay has one synchronization service: Loro plus lorosync.
Honest conflict boundaries
“CRDT” does not automatically mean every character from every concurrent keystroke is interleaved.
Laper's Plate bridge maps screenplay blocks to Loro nodes. Most keystrokes use a fast operation path, and larger transformations reconcile nodes incrementally. When two collaborators edit different screenplay blocks, those changes remain independently addressable. When both replace the same paragraph, the paragraph value is the conflict boundary and the later resolved value wins.
That is node-level collaboration, not a claim of character-by-character merge inside one paragraph. It matches the practical writers' room pattern—people usually work in different scenes or blocks—while keeping the behavior understandable when they collide.
Script history and saved versions provide additional recovery and review tools around the synchronized document. They are not a substitute for the CRDT; they answer different questions about undo and intentional checkpoints.
Opening is server-first by design
Laper requires an online initial synchronization before it permits an existing project to become editable. The client waits for the latest server snapshot, subsequent updates, and an explicit initial-sync-complete signal. Only then does it initialize the schema and mount the screenplay editor.
This is a deliberate data-safety decision. Opening an old local snapshot as if it were authoritative can race the current server document and create destructive containers. IndexedDB remains valuable as a cache, pending update log, and recovery mechanism, but it is not permission to bypass the server-first gate.
Once a project is open, transient network loss is different. Local operations can enter the persistence pipeline, the interface can show a local-editing state, and pending updates can synchronize when the connection returns. A disconnected cloud indicator and a yellow status point distinguish that condition from healthy sync.
Presence is a signal, not the document
Presence answers “who is here?” It does not answer “what is the script?” Laper therefore keeps presence lightweight and project-scoped. The channel is established when the user enters a project and removed when they leave. The visual status of the current user's avatar follows the Loro sync connection rather than pretending that a generic Realtime channel proves document health.
This separation prevents two systems from competing to synchronize the same state:
- Loro and lorosync own screenplay and project CRDT data;
- Supabase Realtime owns only bounded ephemeral or account signals;
- HTTP endpoints reconcile durable AI-task, asset, and credit data where needed.
When Laper's model is a good fit
Choose this model when the team needs one browser-accessible project spanning the page, story planning, comments, and production references. If the requirement is a traditional file-centric production workflow, Final Draft may be the more familiar center. If live co-writing, video chat, and broad device support are the priority, WriterDuet has a mature collaboration-first offering. Our WriterDuet comparison covers that decision in more detail.
Continue to script structure visualization to see what collaborators share, or return to the AI screenwriting software overview.