Google Docs figured out real-time collaboration a decade ago. But Google Docs isn't built for writers. We are.
You're co-writing a story with a friend. They're in Berlin, you're in Moscow. You both want to edit the same chapter at the same time.
What happens on most platforms?
What writers actually need:
Real-time collaboration isn't just "send text over the internet." It's a distributed systems problem that requires solving conflicts when multiple people edit the same location simultaneously.
Imagine two authors editing the same sentence:
Starting text: "The dragon flew."
"The dragon soared.""The dragon quickly flew."Both authors started with the same text. Both made valid edits. But their changes conflict.
What should the final result be?
"The dragon soared." (Author B's change lost)"The dragon quickly flew." (Author A's change lost)"The dragon quickly soared." (Both changes preserved)Getting to that third option—preserving both changes intelligently—requires an algorithm that can transform operations so they work together.
NOVA uses Operational Transformation (OT), the same family of algorithms that power Google Docs, Figma, and other real-time collaborative tools.
Operational Transformation works by breaking every edit into three basic operations:
Every keystroke you make gets translated into a sequence of these operations.
Example: Changing "hello" to "hello world":
1[
2 { type: "retain", count: 5 }, // Keep "hello"
3 { type: "insert", text: " world" }, // Add " world"
4];When two people edit simultaneously, OT transforms their operations so both can be applied without conflict.
1// Author A's operation
2opA = [retain(11), delete 4, insert("soared")];
3
4// Author B's operation (before seeing A's change)
5opB = [retain(11), insert("quickly ")];
6
7// Transform them
8[opA_prime, opB_prime] = transform(opA, opB);
9
10// Now both can be applied in order:
11// 1. Apply opA → "The dragon soared."
12// 2. Apply opB' → "The dragon quickly soared."The transform function is the heart of OT. It takes two concurrent operations and adjusts them so they can be applied sequentially while preserving both authors' intent.
Why not CRDTs? Conflict-free Replicated Data Types (CRDTs) are an alternative approach that works peer-to-peer without a central server. We chose OT because: 1. Better for text editing: OT handles character-level operations more naturally 2. Simpler reasoning: Central server = single source of truth 3. Proven at scale: Google Docs uses OT, not CRDTs We may explore CRDT hybrids for offline support in the future.
All of this happens in milliseconds. You type, they see it instantly.
Most text editors store content as a simple string: "Hello world". Easy to diff, easy to transform.
But NOVA's editor (Lexical) stores content as a tree:
1{
2 "root": {
3 "children": [
4 {
5 "type": "paragraph",
6 "children": [{ "type": "text", "text": "Hello world" }]
7 },
8 {
9 "type": "heading",
10 "level": 2,
11 "children": [{ "type": "text", "text": "Chapter 1" }]
12 }
13 ]
14 }
15}The problem: You can't just diff JSON trees. The structure changes, not just the text.
Extract text: Flatten the tree into a plain text string, inserting \n for block boundaries
"Hello world\nChapter 1\n"
Diff the text: Use Myers' Diff Algorithm (the same algorithm git diff uses) to find changes
Generate operations: Convert the diff into Retain/Insert/Delete
Apply to tree: Reconstruct the Lexical tree from the new text, preserving structure
Why this works:
Performance optimization: Diffing large documents (50k+ words) is expensive. We offload all diff computation to a Web Worker (background thread) so your editor never freezes, even during large pastes or imports.
As a writer on NOVA, you don't see operations or transforms. You see:
Current benchmarks (as of insider beta):
For the technically curious (feel free to skip this section):
Every document has a revision number that increments with each operation. When you send an edit, you include the revision you're based on:
1{
2 docId: "chapter-uuid",
3 operation: [...],
4 baseRevision: 42, // "I'm editing version 42"
5 clientId: "author-a",
6 timestamp: 1637012345678
7}If the server is now at revision 45, it knows your operation needs to be transformed against operations 43, 44, and 45 before being applied.
Redis caches the last 100 operations for each document. This enables:
Each user is limited to 100 operations per second per document. This prevents:
The OT client runs a simple state machine:
What this means:
This ensures operations are sent in order and prevents race conditions.
Every operation is validated server-side:
// Before applying any operation:
You can't:
We're continuing to improve the collaboration system. Planned features:
Real-time collaboration is available to all NOVA authors starting with the insider beta (December 2025).
How to test it:
You can even open the same chapter in two browser tabs and edit simultaneously—it works just as smoothly.
If you're building something similar or just curious about the technical challenges, here are problems we're still exploring:
1. CRDT Hybrid Approach
Could we combine OT (for connected editing) with CRDTs (for offline resilience)? Use OT when online, fall back to CRDT when disconnected?
2. Operation Compression
Large operations (paste 10k words) generate huge operation payloads. Can we compress them intelligently without breaking transform semantics?
3. Branching History
Git-style branching for story alternate endings—but with OT. How do you transform operations across branches? Do branches share a common operation history?
4. Semantic Merge
When two authors write different endings, can an AI suggest an intelligent merge? Or detect when changes are truly incompatible?
If you're researching these topics, reach out—we'd love to collaborate.
Most platforms treat collaboration as an afterthought. "Here's a text box, figure it out."
We treat it as a first-class feature.
Fiction is collaborative. Co-authors, beta readers, editors, writing partners—stories are made better together. The technology should fade into the background and let you focus on the story.
That's what real-time collaboration on NOVA does. You write. They write. The platform handles the rest.
Want to go deeper? We're working on a follow-up post covering:
Subscribe to our newsletter to get notified when it drops.
Yes. Your browser caches all local changes. When the server reconnects, pending operations are synced automatically. You won't lose work.
The server applies operations in order based on revision numbers. Both deletes are transformed to be compatible. The sentence is deleted once (not twice), and both clients converge to the same state.
Not yet in the UI, but it's stored server-side. We're building a "revision history" view that shows all past operations with timestamps and authors. Coming in Wave 2.
You can work solo anytime. Just don't invite co-authors. The system works identically for single-author editing—you're just the only one sending operations.
Yes! The OT system is platform-agnostic. Mobile Safari, Chrome, Firefox—all supported. Though editing long chapters on mobile can be tedious (same as any platform).
What's similar: Real-time collaboration, conflict resolution
What's different:
Stories are meant to be shared. Now you can write them together.
Questions? community@novusatlas.org
Want to contribute? Parts of our OT implementation may be open-sourced soon. Stay tuned.