A joining peer learnt the roster by announcing itself and having every member
reply with their state. That's one broadcast per member — O(N^2) messages for
a room of N — and the in-memory channel layer caps each connection's queue at
100 and drops the overflow silently. Measured with 100 synthetic peers: every
peer ended up seeing only 58-96 of the other 100, permanently. Not cosmetic —
joinable? and mirrors? both read the roster, so you couldn't join someone you
couldn't see, and a mate whose state was dropped wouldn't move you.
The consumer now keeps the roster it is already relaying and hands a newcomer
a snapshot in one message, so a join costs two broadcasts instead of N. Same
100 peers: roster complete and identical for everyone, 2310 messages sent down
to 349, 72.6k deliveries down to 38.6k, server 30% -> 21% of one core, nav
latency unchanged at ~14ms p50.
This is a cache of relayed gossip, not a source of truth: parties are still
worked out entirely in the browsers, and the server still decides nothing
about them. It is process-local, like the in-memory channel layer it sits
next to — if that ever moves to Redis for multiple workers, this moves too.
Measured ceiling for the pathological case (everyone in ONE party, all
mirroring each other): 100 peers ~14ms p50 at 21% of a core, 150 still ~14ms
at 27%, 250 degrades to ~450ms p50 with the roster incomplete again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The project socket already carried scene deltas; it now also carries presence.
The top bar grows a Google-Docs-style cluster of faces, and the menu behind it
groups the room into parties, then everyone flying solo, with a Join on each.
A party has no host — you only join one. Joining someone solo adopts *their
cid* as the party id, so two people clicking Join in the same instant converge
instead of minting two parties of one, and the party outlives whoever was
joined first. Everyone in it drives everyone else: a jump, a scrub or a play
from any member moves all the others. That's why being joined needs consent
("Let others join me", on by default, remembered) and why Leave is one click.
Ordering was the thing to get right. A save is a PUT and a jump rides the
socket, so "create an annotation, then jump into it" can arrive at a peer in
the wrong order. Rather than truncate the stack and strand them at the root, a
nav naming a group we haven't been told about is parked and replayed the
moment the delta lands. Authoring parks it for the same reason: a draft
detaches you from the party so hunting for marks is nobody else's business,
and closing the form replays the park, putting you exactly where the party got
to. Deleting a timeline someone is standing in now pops them out too.
Playback ticks stay off the wire — every member runs the same clip off its own
clock, so streaming positions would only fight them. Only deliberate moves and
transport changes go out, and a play we started because a peer did isn't
echoed back at them.
The socket now reconnects with backoff and, on the way back, re-states the
party id it was carrying and pulls the scene it missed. That catch-up is
deliberately additive: "absent from the server" can also mean "saved a moment
ago", and a wrong deletion costs someone their work.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Script pane: PDF tab beside annotations; "Add script annotation" arms
highlight mode on the draft, ✓/✕ to confirm/cancel, auto-scrolls to the
active annotation's highlights during playback. Adds Project.script.
- Realtime: Django Channels websocket per project broadcasts attributed
scene deltas after each save; peers merge them in (keeping local drafts).
- Logout link in the editor project-bar.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
