Start a video conference
Spin up a private room and share the link. Audio, video, and screen sharing go directly between the browsers on the call — peer to peer. When two browsers have no direct path, that one pair goes through our relay, which forwards the encrypted stream without being able to read it.
New room
How your media stays private
- Audio and video are encrypted end-to-end (DTLS-SRTP) and sent directly between browsers. A pair that has no direct path is relayed by us, still encrypted, still unreadable to us.
- You can check who's on the call at any time — and it doubles as a tripwire if a name you don't expect shows up.
- Rooms auto-expire and are deleted. No accounts, no recordings.
What our server can and can't see
Your media is peer-to-peer. Audio, video, and screen shares are encrypted with DTLS-SRTP, keyed between the browsers on the call. Our server never records or decrypts your media. It runs a STUN server that helps your browsers find a direct path to each other, and — only for a pair that has none — a relay that forwards the encrypted stream without being able to read it.
What the server does see. To set up the call, your browsers exchange connection details (SDP and ICE candidates) and our signaling server relays those between you. They describe how to connect — including IP addresses and codec capabilities — but contain none of your audio or video.
The honest caveat. Because we relay the connection setup, a malicious or compromised signaling server could in principle insert itself in the middle (a man-in-the-middle). Your browsers verify each other's encryption fingerprint, but that fingerprint travels through us — so the cryptography alone doesn't stop us, only our honesty and our open-source code do. We don't do this. If that residual trust is unacceptable, use a tool with out-of-band fingerprint verification.
The roster. The list of who's on the call is a convenience, not a cryptographic identity proof. Names are typed in by each participant and are not verified. Treat it as a tripwire: if a name you don't recognize appears, hang up.
The optional password. If you set one, it's a random value generated in your browser. Your browser sends only a SHA-256 hash of it (bound to this room's id) — the password itself never reaches our server. We store the hash and compare it, in constant time, when someone joins. It keeps out a stranger who has the link but not the password; it does not encrypt your media.
When there's no direct path. If two people are both behind strict ("symmetric") NATs, their browsers cannot reach each other directly, and that pair's media goes through our relay instead. It forwards the same encrypted stream: it can see the IP addresses at each end and how much traffic there is, never the picture or the sound. Only that pair is affected — everyone else on the call stays direct, and that pair's video is capped at 350 kbps so one detour can't run away with the relay's bandwidth. Failing outright is now the rare case: it takes the relay being unreachable too — down, blocked by this network, or stopped past its monthly traffic limit — and when it happens the in-call Stats panel shows each person's network type and what to try, usually just one of the two switching to a phone hotspot or turning off a VPN.
7 people per room. Every browser sends its own video to every other browser, so the connections grow with the square of the group. The server enforces a hard cap of 7 and refuses the next person to arrive. That refusal happens after they have already granted camera and microphone access, so if you are inviting a larger group, split it up before you send the link.
Lifecycle. Rooms expire (3 hours, 24 hours, or 7 days) and are then deleted from the database. Leaving the call removes you from the roster; a missed heartbeat removes you automatically. We never log SDP, ICE candidates, display names, or tokens. The relay keeps its own session log — which addresses it forwarded between, when, and how many bytes, which is everything it is able to know — and that log is deleted after 7 days.