How a private connection works
From the moment you create a meeting to a live, encrypted conversation — every step in plain language, with the deeper detail for the technically curious.
The big picture
You create a meeting
Your browser invents a random meeting name and a secret key. The key is tucked into the end of the link, after the # — the one part of a web address that browsers never send to any server.
You invite someone
You share the link. Opening it needs no app and no account. Because the key travels inside the link, only the people you send it to can read anything.
Your devices connect directly
The two browsers find each other and open a direct, encrypted channel. From then on, messages, files and calls flow straight between you — not through us.
The key lives in the link, not on our servers
Encryption keys are what turn readable text into scrambled data and back again. In most apps the provider keeps a copy of those keys. Here, the key is created on your own device and placed in the part of the link that comes after the “#” symbol — known as the URL fragment.
Browsers treat that fragment as local-only: it is never put into the request that travels to a server. So the secret that unlocks your conversation never reaches us. We could not read your messages even if we were compelled to.
The fragment is read entirely in the browser and used to derive a symmetric key. Because it never appears in the request path, query string or headers, it is absent from access logs, server memory and any intermediary on the way. Possession of the link is the capability; “revoking” access means retiring the meeting, not rotating a secret we hold.
The hard part: two strangers that can’t see each other
Before anything else, there’s a problem to solve. Your two devices usually sit behind home or office routers that share a single public address among many devices and refuse uninvited incoming traffic. Neither device knows a working way to reach the other.
Something has to introduce them to each other — without ever seeing the conversation itself.
This is the classic NAT problem. Most devices live behind Network Address Translation, which maps many private addresses onto one shared public address and only forwards return traffic for connections the device itself started. Two such devices cannot simply “dial” one another; they need a coordinated discovery-and-traversal process.
Signaling: the introduction (the handshake)
To introduce the two devices, each one writes a short note describing how it can be reached and what it supports — which kinds of audio, video and data it can handle. These notes are passed back and forth through a tiny relay we run for exactly this purpose: to hand one note to the other side and bring back the reply.
This step is called signaling. The notes contain connection details only — never the content of your conversation — and they are thrown away the instant the connection is live.
Each side produces a session description: an “offer” from the initiator and an “answer” from the responder, listing media capabilities and transport parameters. They are exchanged over a minimal signaling channel — one side posts its description, the other reads it and replies. That exchange is short-lived and held only in memory; it never observes the encrypted stream that follows.
WebRTC: how browsers talk directly
All of this runs on WebRTC — a standard built into every modern browser that lets two of them open a direct line for audio, video and arbitrary data, with no plugins and no extra software to install. It’s the same family of technology behind most in-browser calling.
WebRTC quietly handles the two hardest parts for us: getting through firewalls, and encrypting the link end to end.
WebRTC (Web Real-Time Communication) is an open standard that exposes peer connections, media tracks and data channels to the browser. It bundles the connectivity machinery, the security layer and media handling behind one interface, so an application gets an encrypted, NAT-traversing transport without having to build those layers itself.
ICE and STUN: finding a path through
To actually connect, each device gathers a list of ways it might be reachable: its address on the local network, and its public address as seen from the wider internet. Discovering that public address means asking a simple helper out on the open internet, “what address do you see my traffic coming from?” That helper is a STUN server.
The whole routine of collecting these candidate paths and then testing which one actually works is called ICE.
ICE (Interactive Connectivity Establishment) gathers candidates: local interface addresses, the public mapping discovered via STUN (Session Traversal Utilities for NAT), and relayed addresses (see TURN, below). The candidates are exchanged and probed in priority order with connectivity checks until a working pair is found — frequently “punching” a hole through both routers by sending outbound packets that prime each side to accept the matching return traffic.
TURN: a relay for the impossible cases — and a privacy shield
Sometimes two networks are locked down so tightly that no direct path exists at all. For those cases there is a relay server, using a protocol called TURN, that simply forwards traffic between the two devices.
Two things matter here. First, the relay only ever handles already-scrambled data — it cannot read your messages. Second, because each side talks to the relay instead of directly to the other, neither device ever learns the other’s real IP address. So the last-resort fallback doubles as a way to keep your location private — and it can be chosen on purpose for exactly that reason.
TURN (Traversal Using Relays around NAT) allocates a relay address that both peers send to; the server forwards packets between them. It carries only the already-encrypted stream, so the operator cannot see content. Routing through the relay also hides each peer’s address from the other, which is why it may be preferred deliberately for IP privacy rather than purely as a fallback. The credentials that authorise relay use are short-lived and issued per session.
Locking the channel: end-to-end encryption
Once a path is found, the two devices agree on encryption keys directly with each other and wrap the entire connection in strong encryption before any real data flows. Audio and video are protected by the secure-media layer built into WebRTC; text and files are additionally sealed with the key that came from your link.
At no point does readable content exist anywhere but on the two devices taking part.
The transport is secured by establishing keys with DTLS and protecting media with SRTP; certificate fingerprints carried in the session descriptions are checked to detect tampering. On top of that, application messages and files are independently sealed with an AES-GCM key derived from the link fragment, giving confidentiality and integrity that are end-to-end and independent of the transport encryption beneath them.
What our servers can — and can’t — see
Add it all up and the picture is simple. We help two devices find each other, and on rare occasions relay scrambled packets between them. We never hold your keys, never see your messages, files or calls, and write no conversation history to storage.
When a session ends, the small amount of handshake data used to connect you is gone.
The entire server-side footprint is: a brief, in-memory exchange of session descriptions and connectivity candidates; optional relaying of opaque encrypted packets; and the issuing of short-lived relay credentials. No content, no decryption keys and no message or attendee records are kept. This is a property of how the system is built, not a setting that could be flipped.
Persistent meetings: reuse the same link
A meeting is simply a link you can reuse. The link stays the same, so you can send it once and meet again later. When a guest opens it, they see a short waiting screen; the moment you — the host — open the meeting from your device, the two of you are connected and the conversation begins.
That waiting screen only ever asks one question — “is the host here yet?” — and never carries any content.
For reusable meetings, a lightweight presence signal indicates when the host’s device is active. A guest who opens the link checks a minimal status report that returns only whether the meeting exists and whether the host is present — no content, no key. Once the host is online, the guest is forwarded into the encrypted channel, where the same signaling-then-direct-connection flow described above takes over.
The words, in one place
Peer-to-peer (P2P)
A connection that runs directly between two devices, instead of through a central server that stores or relays everything.
WebRTC
The browser standard that lets two browsers open a direct, encrypted line for audio, video and data — no plugins required.
NAT
Network Address Translation — the router feature that lets many devices share one public internet address, and which makes direct connections tricky.
Signaling
The opening exchange that introduces two devices to each other. It carries connection details only, never conversation content.
ICE
Interactive Connectivity Establishment — the process of gathering possible network paths and testing them until a working one is found.
STUN
A helper server that tells a device what its public internet address looks like from the outside.
TURN
A relay that forwards encrypted traffic when a direct path is impossible — and which also hides each device’s address from the other.
Session description (SDP)
The short note describing what a device supports and how it can be reached, swapped during signaling.
DTLS / SRTP
The standard layers that establish keys for, and encrypt, the live connection and its audio and video inside WebRTC.
AES-GCM
A widely used encryption method; here it protects your text and files using the key carried in your link.
End-to-end encryption (E2EE)
Encryption where only the two endpoints can read the content — no server in the middle ever can.
URL fragment
The part of a link after the “#” symbol, which browsers keep local and never send to a server.
That’s the whole journey
Create a meeting, share the link, and the rest happens directly between your devices.