Live sync

Save on the Mac, see it in the headset in under a second, and edit back the other way. Here's exactly how the wire works.

Discovery: a server inside Chapter Studio

Chapter Studio embeds a small HTTP server that starts with the app and announces itself on your local network over Bonjour as "Chapter Vision on <hostname>". Chapter Vision browses for that service continuously, so every Mac running Chapter Studio on the same network simply appears in the headset's session list. No IP addresses, no pairing codes.

The server is plain HTTP, which has a nice side effect: point any browser on the network at http://<mac>:<port>/ and you get a human-readable status page showing the served document and connection details.

Connecting: document, assets, events

When the headset connects, it does three things:

1. Fetch the document. GET /chapter.json returns the current chapter exactly as it would be saved to disk: same JSON, same schema (see the ChapterScript format).

2. Stream the assets. Each file in the manifest is fetched from GET /assets/<path>. The server supports HTTP Range requests, so video streams straight into the player and seeks land mid-file without downloading the whole master first.

3. Subscribe to events. The headset opens a long-lived GET /events connection, a standard Server-Sent Events stream, and holds it for the whole session.

From then on, every ⌘S in Chapter Studio pushes a change event down that stream, and the headset refreshes the document and re-applies playback in place, typically in well under a second. You keep watching the same segment; only the changes move.

Edited videos are never stale

Asset URLs carry a content-hash query string derived from each file's fingerprint in the manifest, something like /assets/intro.mp4?v=9f31ab…. Replace or consolidate a video on the Mac and its hash changes, so the URL changes, so every cache between the bundle and the headset's video player treats it as a brand-new file. An unchanged file keeps its URL and stays cached. You never see yesterday's frames.

Editing back: batched, revision-checked ops

Sync is bidirectional. Edits made in the headset don't upload whole documents. Instead, Chapter Vision sends small, semantic edit operations ("retime this clip", "set this entity's transform", "upsert this animation track") batched into a POST /ops request. Each batch declares the document revision it was based on.

Chapter Studio is the arbiter. It applies a valid batch through the same mutation path as local edits (so the entire batch lands as one entry in the Mac's undo stack) and rebroadcasts the applied ops over the event stream to every connected peer. The document revision bumps on every save and every applied batch.

If a batch arrives based on a stale revision, meaning someone else changed the document since the sender last synced, the server rejects it rather than guessing. The sender refetches the current document, and the author re-applies their change against fresh state. Two editors can work simultaneously without silently clobbering each other; the worst case is redoing one edit, never corrupting the document.

Media and saves over the same pipe

Two more routes round out the protocol:

Requirements and scope

Both devices need to be on the same local network (and able to reach each other; see troubleshooting for firewall notes). Everything is LAN-only: nothing about live sync touches the internet, no account is involved, and your media never leaves your network. The protocol is plain HTTP + SSE + JSON on purpose — it's inspectable with a browser and curl, and any conforming player can implement the read-only half.