Rebase is live trivia. I host the show, open a question, and viewers answer for real money. That sounds like a normal real-time event until the livestream becomes the clock.

Two viewers can be watching the same broadcast while sitting at different positions in the stream. If the server tells every phone to open a question at one wall-clock instant, those viewers may see the prompt against different moments in the show. A person who is further behind is not receiving the same experience; they are receiving the same message too early in their playback.

The question therefore has to belong to a timestamp in the program, not only to the instant when I pressed a button.

“Now” is different for every client

In a room, the host can ask a question and everyone hears it together. In a livestream, the word “together” needs a definition. The broadcaster has a position. Every viewer has a position. Transport, buffering, playback, and the viewer's own device can put distance between them.

That means there are two clocks to think about. Wall time tells us when an event was created. Stream time tells us where the viewer is in the program. For the Rebase interaction, stream time is the useful one.

Attaching the question event to a timestamp lets each client encounter it when playback reaches the intended point. The event can be distributed earlier or later in absolute time without changing where it belongs in the show. The viewer who is behind does not need to pretend to be caught up; their question waits for the matching position.

I start with one rule: question timing follows playback timing. The transport and message format can change, but the relationship between the prompt and the program timestamp is the behavior viewers depend on.

Synchronization and low latency are separate jobs

A timestamp-bound event does not eliminate latency. It gives latency a consistent meaning.

Reducing the distance between broadcaster and client still improves the show. A later Rebase test measured around 500 milliseconds between broadcaster and clients. That is a concrete update to the live path, and it makes the interaction feel much closer to the host's moment.

But a low average does not make every client identical. Even at roughly 500 milliseconds, viewers can have different playback positions. The synchronization rule remains necessary because low latency answers “how far behind?” while timestamp binding answers “when should this question appear in this viewer's stream?”

Keeping those concerns separate makes the system easier to reason about. One effort can reduce end-to-end delay. Another can preserve the relationship between content and interaction when delay varies.

The edge cases live on the timeline

Once stream position becomes the trigger, the interesting failures move with it. A client can pause, buffer, reconnect, or jump. The app has to decide what a question means after its intended point has passed and how much state a returning viewer should recover.

I still have to make an explicit decision for each of those cases. The timestamp is the durable piece of information. A wall-clock broadcast says only that something happened. A program timestamp says where it belonged, which gives a client enough context to make a deliberate choice after disruption.

Fairness also depends on the answering window. The prompt, the content cue, and the available response time need to stay related from the viewer's perspective. Synchronizing the opening moment is the foundation for that experience; it does not automatically settle every policy around late or interrupted clients.

Building around the show

The technical solution serves a very physical product moment: I ask a question, and every viewer should feel that the show asked them at the right time. The system should disappear behind that timing.

The first Rebase test puts the timestamp-bound question model on screen. The second records an approximately 500-millisecond broadcaster-to-client path for the next game. Interactive video has to keep the livestream and its questions on the same timeline.

Rebase is testing this in public through Rebase Research. Viewers need to share the same moment in the program even when the network gives every device a slightly different “now.”