Secure by default. Precise about what that means.

• QUIC and WebTransport carry TLS 1.3 as part of the protocol, so no media connection is ever in plaintext.
• Raw QUIC and WebTransport share one UDP port, so there's only one surface to harden and monitor.

• Tracks are encrypted on the device with SFrame (RFC 9605). AES-256-GCM is the default and AES-128-GCM is supported. This is the approach the IETF MoQ working group is standardising in draft-ietf-moq-secure-objects.
• Only the payload is encrypted, so the relay can still cache, deduplicate and prioritise what it can't read.
• Encrypting a 1080p keyframe on an iPhone takes about 54 µs*, against a 33 ms frame budget.
• End-to-end key management, with MLS for small rooms and sender keys for large ones, is in development. Until it ships, we don't call a room end-to-end encrypted. For public broadcasts, the platform manages the keys so that moderation and recording keep working.

* Built to scale: a Rust media plane and a Go control plane, each scaling out horizontally. Measured in lab, tested to 6,000 viewers on one 4-vCPU relay with zero loss; pending further load testing.

• Client tokens are Ed25519-signed, short-lived and scoped to a tenant, a room and an explicit set of grants.
• In the spirit of DPoP (RFC 9449), every token is bound to a key that lives in the device's Secure Enclave, and relays refuse any session that can't prove it holds that key. A token lifted from logs or from memory doesn't work from anywhere else.
• Tokens refresh automatically: the SDK fetches the next one from your backend two minutes before expiry and hands it to the relay mid-session, without reconnecting or dropping the call.
• Every publish, subscribe and fetch is checked against the session's token, whether it carries audio, video, screen share or data. A token that lapses without renewal closes the session.

• Kick or ban someone through the admin API and their open connection closes. You don't have to wait for their token to expire.
• Unbanning someone and closing a room take effect the same way. An end-to-end test covers this: a real control plane, a real relay and a real client.

• Relays and the control plane authenticate each other over TLS 1.3 with client certificates. Certificates are required, not just requested.
• Each relay also presents its own credential, so a stolen credential alone is not enough to pose as a relay.

• Every request is checked against the tenant, room and grants in its token, for every namespace it names.
• Per-device and per-user quotas apply to sessions, subscriptions, announcements, watches and fetches.
• Twenty-one capabilities, such as publishing, moderating or bringing someone on stage, are granted one by one and verified across both backend SDKs and the server.

• An opt-in mode for 1:1 calls and private rooms of up to about four people, in which media goes directly between devices. In this mode the relay carries nothing.
• Only in end-to-end encrypted rooms, and only when every participant opts in. The interface tells them that peers will see each other's IP address.
• Never offered to an audience or for public broadcasts. It falls back to the relay when a direct path isn't available.

• Our own implementation of the MoQ transport draft, with coverage-guided fuzzing of every decoder on every change.
• The QUIC stack is vendored unmodified, and a script verifies it against upstream.
• The relay's admin and metrics port is off by default and bound separately from media.

• QUIC has no unencrypted mode and no way to negotiate TLS down, so every connection is TLS 1.3 from the first packet.
• The relay must prove it owns a certificate for the exact host the app dialled, checked by the operating system, with Certificate Transparency on Apple platforms.
• Relays and the control plane authenticate each other with mutual TLS, so an impostor can't pose as either one.
• A stolen token is bound to the device it was issued to, and is useless anywhere else.

• TLS 1.3 uses fresh keys for every connection (forward secrecy), so recorded traffic stays unreadable even if a server key leaks later.
• With end-to-end encryption on, media and data are sealed on the device with SFrame. Relays, MOQOM and the cloud underneath see only ciphertext.
• Tampering with an encrypted object's position, priority or properties makes it fail authentication, so it is dropped rather than played.

• Pinning causes outages: when a certificate rotates, every app holding the old pin stops connecting until users update. Browsers dropped HTTP key pinning for exactly this reason.
• Short-lived, automatically rotated certificates, system validation and Certificate Transparency catch mis-issued certificates without that risk.
• Self-hosted relays with a private certificate can opt in to exact pinning in the Swift SDK. It's stricter than system trust, takes several hashes so rotation has no gap, and an empty list trusts nothing.