How the System Works
A plain-language tour of the architecture — no code, no credentials, just the shape.
The three pieces
1. The desktop app (on the model's laptop).
The model's camera and microphone stay on her machine. The app captures them, shows her the cockpit (chat, tips, goals), and sends one high-quality feed up to the relay server. She never touches streaming software, scenes or stream keys — all of that is handled invisibly.
2. The relay server.
Receives the single feed and fans it out to every connected platform simultaneously, in each platform's required format. It also holds the platform logins in a secured vault and continuously checks, from the outside, that each stream is genuinely publicly visible.
3. The cloud backend.
Every chat message and tip from every platform is normalised into one event stream and stored. That stream powers the live goal bar and overlays, and builds up session history and earnings records over time.
Why a relay server at all?
Sending four separate streams from a home connection would quadruple the upload requirement and quadruple the ways a stream can drop. One feed up, four feeds out from a data centre means the model needs only an ordinary connection, and platform-facing streams are rock-solid.
Safety posture
- Platform accounts are treated as precious: sessions are isolated per platform, network egress is arranged so traffic looks like a normal residential connection, and automation hard-stops at any identity check or captcha — a human must always be present for those.
- A human is present for every live window during the certification phase.
- The system prefers each platform's official API where one exists, and uses it for events whenever possible.
How this portal stays current
The engineering system is agent-operated: work items live in a machine-readable registry, and the same automation that does the work republishes this portal — board, timeline and docs — so what you see here is generated from the actual project state, not hand-written status reports.