Flow Watch Party

Part of the Plugin data protocol. Packet: Packet-mumcord-watch.

Flow: watch party

A YouTube watch party in one channel. Every participant plays the video in their own player; only invitations, playback commands and the shared playlist travel as plugin data.

sequenceDiagram
    participant A as Client A (starter)
    participant S as Mumble server
    participant B as Client B (same channel)
    participant C as Client C (enters later)
    A->>S: start (video), paused
    S-->>B: relayed, B sees an invitation
    B->>S: join (after clicking Join)
    S-->>A: relayed
    A->>S: cmd play / pause / seek
    S-->>B: relayed, B plays the same position
    B->>S: pl add (playlist entry)
    S-->>A: relayed (edits bundled, at most 1 per second)
    A->>S: next (from, id, video)
    S-->>B: relayed
    C->>S: enters the channel
    Note over A,C: Exactly one participant answers (host, else lowest session)
    A->>S: state (video, playing, position, members, playlist cursor)
    S-->>C: relayed, C can click Join
    A->>S: same state again after about 3 s
    S-->>C: relayed, ignored if the first arrived

Loading

Steps

1. Start. A sends start with a video id to every Mumcord user in the channel who announced watch-party. The party starts paused. B's client shows an invitation; nobody joins automatically.
2. Join. B clicks "Join" and sends join. From then on B's commands and playlist edits are accepted, and B accepts those of other members.
3. Playback. Any member sends cmd with kind play, pause or seek and position_ms. Receivers set their own player to that position.
4. Playlist. Members add (add), remove (rm) and move (mv) entries with pl. Entries are ordered by sort key k; concurrent moves are settled by the higher Lamport clock c. Edits are collected and sent at most once per second, split into several messages when they would exceed 1000 bytes. The list holds at most 50 entries.
5. Next video. When a video ends or someone skips, the client sends next with the entry it left (from), the entry it moves to (id), the video, and skip.
6. Late joiners. When C enters the channel, exactly one participant answers with state: the host while they are in the party, otherwise the participant with the lowest session number. Every client computes the same answerer, so there is one answer, not many. C sees the current video and position and can click "Join". The answerer sends the same state once more about 3 seconds later (REANNOUNCE), because the server silently drops plugin data over its rate limit; C keeps the first state it gets, and a later one only fills in a party C does not know yet.
7. Leaving. leave, or leaving the channel or server, removes the member. The party ends when nobody is left.

Conflicts and rules

• If two parties start at the same moment, the one whose starter has the lower session number wins everywhere.
• Messages from people who are not in the receiver's own channel are ignored; so are commands and edits from people who have not joined.
• Session lists such as members are checked against the people in the channel; at most 32 participants are tracked.
• Video ids must be exactly 11 characters of A-Z, a-z, 0-9, - and _.

Limits and errors

Situation	Result
Version 1 client	Drops pl and next (unknown t) and ignores the new state fields; basic playback still works.
Invalid video id	Message dropped.
Playlist already has 50 entries	Further adds are ignored.
Removed entry added or moved later	Ignored (a removed id stays removed).
Lost message	No acknowledgement (a late joiner's state is sent twice to make a loss less likely). A new state from a late joiner or the next command resynchronises.
Sender not in channel / not joined	Ignored.

Packets used

Packet-mumcord-watch