Guide
How Wisp works
A plain-language explanation of the connection model, the privacy guarantees, and the trade-offs — so you know exactly what you are trusting.
The idea
Most chat apps are a middleman: your messages travel to a company's servers, get stored in a database, and are forwarded to the other person. Wisp removes the middleman. Two devices talk directly to each other using a browser technology called WebRTC.
The only thing our server does is introduce the two devices. After that, it steps out completely.
The two phases of a connection
1 · Introduction (signaling). When you share a code and the other person enters it, the two browsers need to exchange a little technical information — network addresses and encryption setup — to find a path to each other. Our server relays just these small handshake notes. It never sees any message or file.
2 · Direct link. Once the path is found, an encrypted channel opens straight between the two devices. Wisp closes the signaling connection at this point. From here every message and file flows peer-to-peer, and the server carries none of it.
What makes it private
- Always encrypted end-to-end. WebRTC connections are secured with DTLS by default. Only the two devices hold the keys.
- No accounts. No email, phone, or password is ever requested, so there is no identity to store or leak.
- No message storage. Your conversation is never written to any database. Messages and files exist only in the two browsers and vanish when you close the tab. (A tiny database holds active connection codes so two people don't collide on the same one — never any message, file, or identity.)
- Data never touches the server. Chat and files go device-to-device, so there is no server load and nothing to intercept in transit.
What the server can and cannot see
It briefly relays
- The connection code (to match two people)
- Network addresses for the handshake
- Encryption setup messages (not the keys)
It never sees
- Any message you type
- Any file you send
- Who you are — no account, no identity
Choosing a good code
A code is how the two devices find each other, so treat it like a one-time meeting point. Prefer the generated random codes, or invent something hard to guess. Share it over a channel you trust, and ideally use each code only once. If someone else guesses or reuses your code before your peer joins, they could land in the room instead — which is why a code links exactly two people and rejects a third.
Good to know
Honest limitations
- Both people must be online at once. Because nothing is stored, there is no offline delivery. It is a live connection, like a call.
- No history. Close the tab and the conversation is gone. That is the point — but it means you cannot scroll back later.
- A few strict networks need a relay. Most connections are fully direct via public STUN. A small share of locked-down corporate or mobile networks may need an optional TURN relay, which still only carries encrypted data it cannot read.
- Very large files use device memory. Received files are assembled in the browser before you save them, so extremely large transfers depend on the receiving device having room.
- Calls need HTTPS or localhost. Voice and video use the same peer-to-peer connection (their setup is signaled over the encrypted data channel, never the server). But browsers only grant camera/microphone access on a secure origin, so a call needs HTTPS or localhost — a plain LAN address will be blocked by the browser.