Distributed Mesh — Overview

The system could have been built with a central server: one Mac that all iPhones connect to, coordinating all decisions. That was the original architecture (the multicam-server at `:9404`). The distributed architecture replaced it for specific reasons: - **No laptop in the room**: for outdoor shoots, location shoots, and portable setups, there's no Mac. The distributed model makes the system work on any shared WiFi, including a phone hotspot. - **Single points of failure hurt**: if the Mac goes down, the show stops. In the distributed model, each device is self-contained. - **The devices already have everything they need**: iPhones have cameras, microphones, processors, and network stacks powerful enough to run the full pipeline independently. There's no reason to centralize functions they can perform locally. - **Less total code**: the distributed model deletes the dependency on a 13,000-line Rust server (multicam-server) instead of porting it to yet another platform. **[camera-node-contract.md](camera-node-contract.md)** — The full HTTP + SSE API contract that every camera node (iPhone) must implement: all endpoints, request formats, response formats, error handling, Bonjour advertisement spec. **[stageview-console.md](stageview-console.md)** — How StageView discovers nodes, manages connections, fans out commands, displays live feeds, and shows the contact sheet. The three discovery paths (Bonjour, mDNS hostname prober, subnet scanner). **[mesh-topology.md](mesh-topology.md)** — The full device map: every device, its role, its IPs (LAN + Tailscale), what services run on it, and how devices connect to each other.