Kibitz is peer-to-peer. Your audio and video travel directly between the browsers in the call, encrypted end-to-end — there is no media server that can decode, mix, or record them. Here's the whole path.
Calls use WebRTC. Audio and video are encrypted with DTLS-SRTP, and the keys are negotiated directly between the two browsers — they never leave your devices. So no relay or server in the path can see or hear the call, and there is no SFU or media server that decodes, mixes, or records anything. The one assumption is that those keys are verified honestly — which happens in the signaling step below, and which you can check yourself with the safety code (§4).
Two browsers can't find each other unaided, so a signaling server briefly exchanges the setup data needed to connect: a temporary peer ID, the room name from your link, and network "ICE candidates" (which include IP addresses). It sees connection metadata, never call content, and stores none of it.
Signaling is also where the two browsers verify each other's encryption keys — each publishes a certificate fingerprint here. We relay those honestly and keep nothing; but because verification rides this channel, a compromised or compelled signaling server is the one party that could attempt to slip into the middle of a future call (a relay can't — it only ever sees ciphertext). That's exactly what the safety code is for.
Some networks (symmetric NAT, strict firewalls) won't allow a direct connection. For those, an encrypted TURN relay forwards the media so the call still works. Crucially, it forwards the already-encrypted packets and cannot decrypt them — it only ever sees ciphertext, IP addresses, and traffic volume. Most calls never need it.
Every WebRTC "end-to-end" claim ultimately trusts the signaling channel to deliver the right keys. To remove that trust entirely, compare a safety code: Kibitz derives a short emoji code from the two browsers' actual certificates — the ones really used on the wire, not the ones named in signaling. If both of you see the same code, no one is in the middle; if they differ, someone is. Same idea as Signal's safety numbers.
This is live in the call UI: tap the shield button in the panel header to open Verify. It shows one emoji code per person — read it aloud, and if it matches on both screens, mark it verified. The code is computed per-pair from the live DTLS certificates, never from anything the signaling server could forge. If someone reconnects with different key material mid-call, the shield turns amber and that person's row warns you to re-check — so a swapped certificate can't quietly inherit an old "verified" badge.
Not a call that's already happening. Its keys are ephemeral, per-call, and held only by the two browsers — there's nothing for us to produce and no kill-switch to pull. The one theoretical avenue is the signaling channel for future calls (swapping a key during setup) — and that is precisely what the safety code (§4) is designed to catch. (We can be made to take the website down — but not to silently reach into your calls.)
You don't have to depend on kibitz.chat. The full source is open (AGPL-3.0) — read it, audit the encryption yourself, build it, and host a copy on any static host or content-addressed on IPFS, so a copy can outlive this site. Read the source →
Found a vulnerability? Please report it privately to [email protected] rather than disclosing it publicly, and give us a reasonable chance to fix it. Thank you.