Glossary

Comprehensive reference of key terminology used in Vuer-RTC.

Acknowledgement (Ack)

Server confirmation that a message has been received and persisted. When a client commits edits to the journal, entries start with ack: false. Upon server acknowledgement, the journal entry is updated to ack: true, indicating the message is safe to compact into the snapshot.

Bloom Filter

A probabilistic data structure for testing set membership. Used in Vuer-RTC to efficiently detect which messages a client has already seen during synchronization, reducing network traffic by avoiding retransmission of duplicate messages.

ClientState

The complete state of a client session, including:

• graph: The current computed scene graph
• journal: Committed message log with acknowledgement tracking
• edits: Uncommitted operations buffer
• snapshot: Compacted checkpoint for fast replay
• lamportTime: Total ordering timestamp
• vectorClock: Causal ordering mechanism
• sessionId: Unique client identifier

Compaction

The process of folding acknowledged journal entries into the snapshot to reduce memory usage and replay time. During compaction, operations from acknowledged messages are permanently applied to the snapshot graph, and those journal entries are removed. Messages marked as deleted (via deletedAt) are skipped during compaction, effectively garbage collecting undone operations.

CRDT (Conflict-free Replicated Data Type)

A data structure designed for distributed systems that guarantees eventual consistency without requiring coordination. Multiple replicas can be updated independently and concurrently, and will converge to the same state when they have received the same set of updates. Vuer-RTC implements a journal-based CRDT with explicit operation types.

Edit Buffer

A buffer of uncommitted operations accumulated during interactive gestures (e.g., dragging, typing). Operations in the edit buffer are merged where possible (additive operations like vector3.add accumulate, LWW operations like vector3.set replace). When the gesture completes, the edit buffer is compacted into a single message and committed to the journal.

Journal

The committed message log tracking all operations sent by the client. Each entry contains:

• msg: The CRDT message with operations and metadata
• ack: Acknowledgement status from server
• deletedAt: Timestamp if the message was undone (soft delete)

The journal enables replay for rebuilding the graph and supports synced undo/redo across clients.

Lamport Time

A logical clock providing total ordering of all messages across distributed clients. Each message includes a lamportTime value that increments monotonically. When receiving a remote message, a client updates its Lamport time to max(local, remote) + 1. Used by Last-Write-Wins operations to determine which update takes precedence.

LWW (Last-Write-Wins)

A conflict resolution strategy where concurrent updates are resolved by selecting the operation with the highest Lamport timestamp. Operations marked as LWW (e.g., vector3.set, color.set, string.set) compare timestamps during merge and keep only the most recent value.

Operation (otype)

An explicit, typed operation with a defined merge behavior. The otype field (e.g., 'vector3.add', 'node.insert') specifies both the data type and the merge semantics. Operations are flat data structures with fields like key (target node), path (property path), value, and operation-specific parameters.

Common operation categories:

• LWW operations: *.set (last-write-wins based on Lamport time)
• Additive operations: *.add, *.concat, *.push (accumulate values)
• Meta operations: meta.undo, meta.redo (journal manipulation)

RLE (Run-Length Encoding)

A compression technique used in TextRope where consecutive characters inserted by the same agent are stored as a single span. Instead of storing individual characters, RLE stores multi-character strings, reducing memory usage and improving iteration performance. For example, typing "hello" results in one span item containing "hello" rather than five separate items.

SceneGraph

The computed hierarchical graph of nodes representing the current state of the collaborative scene. The scene graph is derived by applying the snapshot, then replaying the journal (skipping deleted entries), then applying pending edits. Nodes are stored in a flat dictionary keyed by unique node IDs, with parent-child relationships tracked via children arrays.

Snapshot

A compacted checkpoint of the scene graph state at a specific point in the journal. The snapshot includes:

• graph: The scene graph with all acknowledged operations applied
• vectorClock: The vector clock at the snapshot point
• journalIndex: Count of journal entries baked into this snapshot

Snapshots enable fast replay by avoiding reprocessing of old acknowledged messages. Soft-deleted messages (with deletedAt set) are excluded during snapshot compaction.

Tombstone

A soft-deleted node or text item that remains in the data structure for CRDT consistency. When a node is removed via node.remove, it is marked with deletedAt rather than being immediately purged. Tombstones allow other clients to correctly merge concurrent operations on deleted nodes. Tombstones are eventually garbage collected during compaction.

Vector Clock

A causal ordering mechanism tracking the logical clock of each client session. Represented as { [sessionId]: lamportTime }. Vector clocks enable detection of causal relationships between messages:

• If clock_a[session] <= clock_b[session] for all sessions, then message A causally precedes message B
• If neither clock dominates, the messages are concurrent

Used to merge clocks during synchronization: merged[session] = max(clock_a[session], clock_b[session]).

YATA (Yet Another Transformation Approach)

A text CRDT ordering algorithm that reduces interleaving of concurrent edits compared to pure RGA (Replicated Growable Array). YATA orders insertions by:

1. Lamport timestamp (higher timestamp inserts first)
2. Parent position (if timestamps equal, compare parent positions)
3. Agent ID (if still equal, use agent ID for deterministic ordering)

This ensures that concurrent edits from the same agent stay together, improving collaborative editing quality.