# Encrypted P2P Video Calling (WebRTC Mesh) — Pondchat

> Direct peer-to-peer audio/video/screen. No Pondchat media servers, no SFU, mesh capped at 2–6.

## Architecture

Each browser negotiates DTLS-SRTP with every other peer. Cloudflare Workers handle ephemeral signaling. TURN only when a direct path fails.

## Encryption layers

- **Media:** DTLS-SRTP between peers (or peer↔TURN).
- **Text chat:** Client-side AES-GCM; key derived from the room URL. Server holds ciphertext only while occupied, then wipes it.
- **File transfer:** P2P `pond-file` RTCDataChannel — DTLS-encrypted like media; chunked in browser (16 KiB), capped at 100 MB, accepted per-recipient; never uploaded or stored.
- **Signaling:** SDP/ICE relay — not a transcript archive.

## Limits by design

Mesh favors low latency for small groups. Large webinars need an SFU; Pondchat does not become one.

## Where TURN fits in

About 10–20% of connections cannot find a direct path because of symmetric NATs or strict firewalls. Pondchat then relays packets through Cloudflare TURN. TURN forwards already-encrypted DTLS-SRTP packets and cannot decrypt them; it is a pipe, not a media server.

## Threat model in one paragraph

Pondchat protects media and chat content from the Pondchat server and from anyone who is not in the room. It does not protect against a participant recording their own screen, a compromised browser, or someone who obtains the room link. Room links are capabilities: share them like passwords.

## Related

- [No-signup video chat](https://pondchat.com/features/no-signup-video-chat)
- [Signaling docs](https://pondchat.com/docs/api/signaling.md)
- [llms.txt](https://pondchat.com/llms.txt)