Low-latency live streaming: separate creator and viewer access

First: what are we talking about?

Imagine an online class or a live game stream. A creator sends audio and video, while many viewers should receive them with little delay. Instead of sending a separate copy directly to every viewer, the creator can publish the stream through an intermediate server called a relay.

Media over QUIC, shortened to MoQ, is a protocol for media delivery with a publish-and-subscribe model that the IETF is still developing. It uses QUIC, a network transport protocol. A publisher publishes a stream, a subscriber subscribes to it, and a relay helps distribute the media.

Cloudflare has introduced a beta API for creating isolated MoQ relays. It can separate publishing and subscribing permissions, set credential lifetimes, and revoke tokens. This is one Cloudflare implementation, not a finished universal standard for every MoQ service.

Why a working demo is not ready for a pilot

The video now arrives without a noticeable delay, and the team wants to invite its first viewers. It still needs to answer a simple question: do viewer credentials truly allow watching only? If not, the holder of those credentials may be able to publish another stream.

Separate creator and viewer permissions before inviting users. Verify that a viewer token cannot publish and that an expired or revoked token cannot authorize a fresh access attempt. Test an already active session separately because its behavior depends on the implementation and when the token is checked.

What an isolated relay adds

A public test relay may be convenient for an initial experiment. If it accepts clients without credentials from your application, it cannot enforce your application’s user checks, role separation, or access lifetime. A pilot with real people needs a managed access boundary, such as an isolated relay or relay scope.

In this article, isolated means a relay or relay scope that is not open to every test client. Check the implementation documentation for the exact isolation boundary and the way the resource is identified. Do not assume without verification that it is a separate server instance.

Cloudflare reports support for draft-14 and draft-16. This does not prove that a client using one version can interoperate with a relay using the other, or that any additional drafts are supported. Test only documented combinations and record the version of every test participant.

Beta status is not a promise of production readiness. Each team must separately assess service limits, error behavior, and the effect of expiration or revocation on active sessions.

Keep access management separate from media delivery

Access management is separate from media delivery. A trusted server-side component creates an isolated relay or scope and issues or revokes credentials. Media clients use those credentials to publish or receive a stream. The specific APIs, resource names, and sequence of operations depend on the implementation.

Administrative credentials must not appear in a browser, mobile application, or client-side log. Keep them on the trusted server side and separate from media-client tokens.

Start a small pilot with this least-privilege model:

• the creator token permits publishing but not viewing unless the scenario requires it;
• the viewer token permits viewing but not publishing;
• every test token has a limited lifetime;
• revocation of one token is tested independently of other valid tokens;
• administrative credentials remain separate from media clients.

If one client genuinely needs both operations, grant them deliberately and record the choice in the access matrix. Do not make combined access an implicit rule for every client.

Do not rely on a hidden relay address as access control. Accidentally sharing a URL must not, by itself, grant permission to publish or subscribe.

A pre-pilot test card

Start with the documentation and the normal path. Only then move to role, expiration, and revocation tests.

1. Record the test boundaries. Capture the implementation, its status, client and relay builds, their draft versions, and documented supported combinations. Mark unknown behavior as unknown rather than guessing.
2. Test the normal path. The creator sends a test stream, and the viewer receives it. Record the time, versions, and a redacted result without tokens or private addresses.
3. Change the action, not the token. Try to publish a test stream with the viewer token. The operation should fail in a controlled way. Separately verify that this attempt did not disrupt an independent valid session.
4. Test expiration. First perform an allowed operation with a short-lived test token. After expiration, start a fresh session and repeat the operation. The expired token must not grant the stated access again. Test an active session separately according to the documentation.
5. Revoke one test token. After revocation, start a fresh session and repeat the protected operation. Then test an already active session separately. Another valid token should retain its documented permissions if the implementation promises independent revocation.
6. Check the version matrix. Test documented supported pairs first. If the documentation explicitly identifies an unsupported combination and its expected failure, test that pair in an isolated environment. Do not invent an expected error code.
7. Apply stop criteria. Do not open the pilot to users if a viewer can publish, an expired or revoked token authorizes access again, or active-session behavior contradicts the documentation.

Unstable behavior from a documented version combination is also a reason to stop. The same applies if another valid token fails after targeted revocation when independence is promised, or if a session remains partially functional in an unpredictable way.

Anti-patterns to remove

One shared token for both roles does not allow one role’s permissions to be revoked independently of the other. An unnecessarily long lifetime increases the impact of a leak. Testing only the successful path does not prove that restrictions work.

Do not assume that revocation always terminates an active connection immediately. Do not treat support for draft-14 and draft-16 as automatic cross-version interoperability. Do not embed beta API method names or commands in the core architecture as though they were part of a universal MoQ standard.

Where AI can help

AI can turn a redacted role matrix into a set of negative tests. Provide placeholder role names, draft versions, the documented compatibility matrix, test token lifetime, and expected failure categories. State known expectations for new and active sessions separately.

Ask the model to produce actions, expected results, stop criteria, and a list of assumptions. Tell it not to invent error codes or behavior missing from the inputs.

Do not provide real tokens, private relay addresses, administrative keys, identifiers, or complete logs. Check every proposed scenario against the implementation’s official documentation and run it in an isolated test environment.

The result that matters

Low latency alone does not make a stream ready for a pilot. The team must show that publishing and viewing permissions are truly separated, expiration and revocation have been tested, and protocol versions are known and included in a documented compatibility matrix.

For active sessions, do not rely on assumptions. Record the documented expectation, verify it in the test environment, and stop the pilot if the observed result differs.

Sources

• Cloudflare — An API for MoQ: provision your own isolated relays