Skip to main content

Real-time Collaboration

Yugma supports real-time multi-user collaboration powered by Firebase Realtime Database.

How It Works​

Connection Flow​

  1. The owner opens Collaboration in the Studio settings and creates a room.
  2. A signed-in collaborator enters the room code and selects Request access.
  3. The host checks the requesting account ID and approves or declines. A code alone does not reveal the scene.
  4. Approval records membership before the collaborator loads the snapshot and connects presence, cursors and scene deltas.
  5. Leaving removes the collaborator's membership. Closing or expiring the room blocks further reads and writes.

A waiting collaborator can cancel their request. The host can review requests in the same Collaboration controls. Display names are not verified identity; confirm the account ID through a trusted channel before approving.

Delta Synchronization​

When a user modifies the scene (for example, moves an object), the change is broadcast as a delta — a minimal diff describing what changed:

{
"uid": "user_xyz",
"objectId": "abc123",
"action": "update",
"transform": {
"position": [1, 2, 3]
},
"ts": 1234567890
}

Cursor Sharing​

Each user's 3D cursor position is shared in real-time, allowing collaborators to see where others are working in the scene.

Architecture​

Firebase Realtime Database Paths​

/collab/{sessionId}/
/presence/{uid} — User online status (displayName, color, online)
/cursors/{uid} — 3D cursor position
/deltas/{deltaId} — Scene change deltas
/rooms/{roomCode} — Host-owned scene snapshot, expiry and approved members
/roomJoinRequests/{roomCode}/{uid} — Request and approval status (requester/host only)

Conflict Resolution​

Yugma uses a last-write-wins strategy for conflicting edits. If two users modify the same object property simultaneously, the last delta received is applied. Concurrent edits can overwrite each other; this does not provide conflict-free merging.

Limitations​

  • Maximum recommended collaborators per session: 8

  • Delta history is ephemeral — only the latest state persists in the project save

  • Cursor sharing updates at ~10fps to limit bandwidth

  • Room snapshots are bounded to 4 MiB and individual delta strings to 1 MiB by rules (string-length units), with additional client byte checks.

  • Aggregate history, membership/request count and storage quotas require separate admission controls; the recommended participant count is not an enforced quota.

  • Revocation stops future server access. Data already loaded or copied by an admitted collaborator cannot be recalled.