// the find
synctv-org/synctv
Synchronized viewing, theater, live streaming, video
SyncTV is a Rust backend for synchronized group video watching, plus live streaming ingest/relay (WHIP/RTMP in, WHEP/HLS/HTTP-FLV out) and pull-through-relay from external sources. It's aimed at people self-hosting a Kubernetes-scale watch-party/streaming service rather than someone wanting a weekend script.
Real production posture: Postgres for durable state, Redis for shared cache/rate-limiting/cluster coordination, Helm charts and a Docker Compose path — this isn't a single-binary toy. Auth uses OPAQUE (an augmented PAKE) alongside WebAuthn/passkeys and TOTP, which is a notably stronger choice than the usual bcrypt-over-TLS setup most side projects ship. The media/live-streaming surface is unusually wide for one project — WHIP/RTMP publish, WHEP/HLS/HTTP-FLV playback, and cross-node relay for pulled external streams — each of those protocols alone is a real engineering lift. sqlx's offline query cache is checked in (hundreds of `.sqlx/query-*.json` files), meaning all SQL is compile-time verified against the schema, which catches a whole class of runtime DB bugs before they ship.
The README never explains the actual sync mechanism — no discussion of clock skew handling, buffering strategy, or how room state conflicts resolve when someone seeks or lags, which is the one thing this project is supposed to be good at. There's no quickstart in the README itself: despite having `.env.*.example` files and Docker/Helm workflows, you have to go hunting for the compose command instead of copy-pasting it. No numbers anywhere — no benchmarks, no load-test results, nothing backing the 'Kubernetes-ready horizontal scaling' claim. The native client isn't in this repo at all — it's a separate `synctv-app` project distributed through app stores, so self-hosters inherit whatever release cadence and feature parity that separate project has, which the main repo doesn't control.