60c4096d2f
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>
|
||
|---|---|---|
| scenes | ||
| server | ||
| tl | ||
| .dockerignore | ||
| .gitignore | ||
| DEPLOY.md | ||
| Dockerfile | ||
| fly.toml | ||
| manage.py | ||
| README.md | ||
| requirements.txt | ||
scene_analysis
tl/— the lumet frontend (ClojureScript / reagent / re-frame). Seetl/.- Django backend (this folder) — users, admin, and persistence of OTIO + the timeline scene.
Backend
The backend stores one Project per editing session: the uploaded OTIO
source file, the playback fps, and the live scene (the {:tracks :groups} mark-group map the frontend keeps in app-db) as a JSON dump.
Run
python -m venv .venv && .venv/bin/pip install -r requirements.txt
.venv/bin/python manage.py migrate
DJANGO_SUPERUSER_PASSWORD=admin .venv/bin/python manage.py createsuperuser --noinput --username admin --email admin@example.com
.venv/bin/python manage.py seed_demo # demo project from tl/.../one_two_three.otio
.venv/bin/python manage.py runserver 0.0.0.0:9001 # 0.0.0.0 so it's reachable over Tailscale/LAN
Admin: http://127.0.0.1:9001/admin/ (admin / admin). Upload OTIO and inspect the scene JSON there.
API (session auth; 401 if not logged in)
| Method | Path | Purpose |
|---|---|---|
| GET | /api/projects/ |
the current user's projects |
| GET | /api/projects/<id>/scene/ |
{fps, scene} |
| PUT | /api/projects/<id>/scene/ |
replace scene and/or fps (JSON body) |
| GET | /api/projects/<id>/otio/ |
serve the uploaded OTIO file |
| GET | /api/projects/<id>/revisions/ |
save history (who / when / summary) |
Attribution
Annotations are the authored unit, so that's what's attributed — and the server
is the authority (client-sent stamps are ignored, so authorship can't be
forged). On each scene PUT the server diffs incoming annotation groups against
the stored ones and stamps createdBy/editedBy (+ timestamps) from
request.user; it also writes a Revision (user, time, +N ~N −N summary,
snapshot of the annotation layer). A project is editable by its owner and any
collaborators (managed in the admin), so different users get distinct stamps.
The frontend currently loads /one_two_three.otio and persists annotations to
localStorage; pointing it at /api/projects/<id>/otio/ and the scene endpoints
is the next wiring step (CORS/credentials needed across the dev ports).