English for Liveblocks Developers

Building collaborative, multiplayer features (like Figma-style cursors or Google-Docs-style co-editing) introduces a vocabulary distinct from typical request-response web development — presence, conflict resolution, and CRDTs all describe specific, nameable behaviors a team needs to discuss precisely rather than lumping together as “the real-time stuff.” This guide covers the English used when discussing Liveblocks-based collaborative features with a team.

Key Vocabulary

Presence — ephemeral, per-user state (like cursor position or current selection) broadcast to other connected clients in a room, not persisted once the user disconnects. “Don’t put the document content in presence — it’s ephemeral and disappears when the user disconnects, we need storage for anything that has to survive a refresh.”

Storage — Liveblocks’ persistent, conflict-free shared data structure for a room, synced in real time across clients and durable across sessions, unlike presence. “The comment thread needs to be in storage, not presence — otherwise it vanishes the moment the person who created it closes their tab.”

CRDT (Conflict-free Replicated Data Type) — a data structure designed so concurrent edits from multiple clients can be merged automatically without conflicts, without needing a central lock or manual conflict resolution. “Two people typed in the same list at the same time and both edits appeared correctly — that’s the CRDT resolving the concurrent operations automatically, no merge conflict dialog needed.”

Room — an isolated real-time collaboration session (typically mapped to one document or one page) that clients join to share presence and storage with each other. “Each document should be its own room — if we put every document in one shared room, presence updates for unrelated documents would flood every client unnecessarily.”

Optimistic update — applying a local change to the UI immediately, before the server or other peers have confirmed it, then reconciling if the eventual authoritative state differs. “The cursor feels laggy because we’re waiting for a round trip before moving it locally — apply the optimistic update immediately, and let the sync layer handle reconciliation in the background.”

Awareness — the general concept (of which “presence” is Liveblocks’ specific implementation) of clients knowing what other connected clients are currently doing, such as who’s online and where their cursor is. “The ‘who’s viewing this page’ indicator is an awareness feature — it doesn’t need to be durable, it just needs to update quickly as people join and leave.”

Common Phrases

• “Should this be presence or storage — does it need to survive a disconnect?”
• “Is this conflict actually being resolved by the CRDT, or do we need custom merge logic?”
• “Should this be its own room, or shared with other documents?”
• “Is this update optimistic, or are we waiting for server confirmation before showing it?”
• “Is this an awareness feature, or does it need to be durable data?”

Example Sentences

Reviewing a pull request: “This stores the user’s current cursor position in the persistent storage object — that should be presence instead, since we don’t need cursor history to survive a page refresh.”

Explaining a design decision: “We modeled the shared task list as a CRDT-backed storage list specifically so two people reordering tasks simultaneously wouldn’t create a conflicting, broken state.”

Describing a bug: “Edits from one user were briefly overwriting another’s because we were treating storage updates as last-write-wins instead of trusting the CRDT’s built-in merge behavior.”

Professional Tips

• Say “presence” versus “storage” precisely — the durability distinction determines the entire data model and is the first question in any Liveblocks design discussion.
• When debugging conflicting edits, ask “is the CRDT handling this merge, or are we overriding it with custom logic?” — custom logic on top of a CRDT is a common source of unexpected conflicts.
• Use “room” to mean the isolated collaboration scope — getting the room boundary wrong (too broad or too narrow) is a common early design mistake.
• Distinguish “optimistic update” (shown immediately, reconciled later) from a “confirmed update” (shown only after server acknowledgment) when discussing perceived latency in collaborative UIs.

Practice Exercise

1. Explain in two sentences the difference between presence and storage in a collaborative app.
2. Write a one-sentence code review comment recommending a value be moved from storage to presence.
3. Describe, in your own words, what a CRDT does and why it removes the need for manual conflict resolution.