What is available
Campus sends your service to screens at other sites, in two modes:
Campus (Live)... under a second, over WebRTC. Any screen with a browser is the decoder.
Campus (Safe)... a 40-second buffer that rides out a dropout without going dark.
Both on MAX with the Campus add-on, included at ALPHA.
Why two modes and not one
Because a second site is a room, not a viewer, and rooms differ in one specific way: whether they interact with the origin.
Sites that are in contact (a shared start time, people texting family across sites, anything where both rooms are aware of each other) need to be close in time. A lag of thirty seconds is uncanny: one room applauds, and half a minute later so does the other.
Campus (Live) is for those. Under a second means the two rooms are effectively together.
Sites that receive independently (a room that watches, with no back-channel) care about something else entirely. They will never notice being forty seconds behind. They will absolutely notice going black for four.
Campus (Safe) is for those. The buffer means a brief network interruption is invisible; the far room keeps playing from reserve while the connection recovers.
The trade, stated plainly
There is no mode that is both, and any product claiming otherwise is hiding something.
Low latency has almost no reserve. That is what makes it fast. A hiccup is visible because there is nothing held back to cover it.
A buffer costs exactly what it holds. Forty seconds of protection is forty seconds behind. That is not a tuning inefficiency; it is the definition.
How to choose: if the two sites communicate during the service, take Live. If the second site simply receives, take Safe. If the far site's connection is unreliable, take Safe regardless... a room that never sees an interruption is worth more than a room that is a few seconds ahead.
Who benefits
Multi-site venues running one service across buildings.
A church plant in a rented room, receiving from the main site.
An overflow space that is genuinely elsewhere... not the hall next door, which should stay on your own network, but a different building.
Anyone whose second site has an unreliable connection, which is where Safe earns its place.
What the far site needs
A screen with a browser. That is the decoder. Smart TV, laptop, tablet, an inexpensive stick behind a monitor. Nothing specialist.
Enrolment, once. An invite link and an authenticator code. After that the screen reconnects by itself whenever it is switched on... nobody at the far end logs in before each service.
That last point is what makes multi-site sustainable for volunteer teams. A second site that needs a technical person present every week has not solved distribution; it has created a second staffing requirement in a building that probably has fewer volunteers than your main one.
Somebody to turn it on. That is the whole job.
A plan for when it fails. Someone at the far site should know what to do if the screen goes dark... who to call, whether to wait. Not because failure is likely, but because a room of people needs someone with an answer.
Practical notes
Measure your own delay and know the number. Live is under a second in normal conditions; conditions vary. Knowing your actual figure lets you decide whether it matters.
Wire the far site if you can. A fixed connection beats wireless for a receiving screen that never moves.
Test at service time, not on a quiet afternoon. Networks are busy at different hours.
Screens on mobile data may need Relay. If the far site is on a carrier connection, that is the case Relay exists for.
Available now on MAX with the Campus add-on.