Collaborative Playlist · Synthesis deep dive
Concurrent Editing Semantics
Clients stay responsive through optimistic changes. Stable identities and a per-playlist commit order produce one canonical list under races, retries, and reconnects.
Client state
- Canonical snapshot: latest server-confirmed entries and version.
- Pending operations: ordered local intents awaiting acknowledgement.
- Rendered list: canonical snapshot with pending operations replayed.
- Connection cursor: last applied playlist version.
- Ephemeral state: collaborator presence, selection, and drag preview.
Race table
| Concurrent operations | Resolution contract |
|---|---|
| Move A + move A | Server order selects the final placement; both accepted events remain observable. |
| Remove A + move A | Removal makes the later move a successful no-op or a typed conflict. |
| Insert X + insert Y at one gap | Both survive; version and actor or operation ID provide a deterministic tie-break. |
| Remove one duplicate track | Entry ID removes the selected occurrence. |
| Retry after lost acknowledgement | Operation ID returns the original accepted result. |
| Permission revoked during edit | Authorization at commit rejects the pending mutation and the client rolls it back. |
Move payload
{ type: "move", entry_id, after_entry_id, before_entry_id }Neighbor identities carry intent across intervening edits. The server validates surviving anchors, chooses a current gap, assigns a new position key, and returns the canonical placement.
Reconnect
- Reconnect with playlist ID and last applied version.
- Receive ordered mutations after that version.
- Apply events to the canonical snapshot and remove acknowledged local operations.
- Rebase remaining local operations by stable entry identity.
- Fetch a fresh snapshot when history retention or compaction creates a gap.
When a list CRDT fits
A list CRDT fits sustained offline editing or peer-originated operation streams. The move operation needs first-class semantics so concurrent moves preserve a single occurrence and converge. A server-ordered protocol provides a smaller interview baseline for an online collaborative playlist.
Test scenarios
- Two users drag the same entry simultaneously.
- Delete arrives while a move is in flight.
- One client misses versions and reconnects.
- The mutation request commits while the acknowledgement is lost.
- A playlist contains three copies of one track.
- Position keys exhaust the available gap during high churn.