WebRTC Without a Server at All
Last post, we traded the WebRTC signaling server for ATProto: offers and answers as short-lived records in each peer's own repo, no relay to deploy. That removed the server we had to run, but a server still sat in the loop — your PDS carried the rendezvous, Constellation indexed it, polling paced it, and both sides needed accounts and app passwords to play. It also meant you had to know who you were connecting to; the whole design keyed on DIDs.
The follow-up question was obvious in hindsight: what is the signaling channel actually for? WebRTC needs each side to hand the other one blob of session-setup text, once. That's it. Every signaling architecture — WebSocket relay, ATProto records, carrier pigeon — is a delivery mechanism for two notes. And if the notes are small enough, the humans standing next to the browsers can pass them.
FileDrop now does exactly that. No ATProto, no accounts, no login, and no server anywhere in the rendezvous.
Making the note small enough to pass
A raw SDP offer runs about a kilobyte, most of it boilerplate that is identical for every data-channel connection. So FileDrop doesn't send the SDP — it extracts the handful of values that actually vary (ICE credentials, DTLS fingerprint, network candidates) into a packed binary format and reconstructs the rest on the other side. Modern browsers hide your LAN address behind a UUID mDNS hostname, which is 42 characters of text but only 16 bytes of UUID, so those pack as raw bytes too. A real answer from an iPhone lands around 130 bytes — about 175 characters of base64url.
At that size, the whole exchange fits in URLs. The invite is a link with the offer in its #fragment — the one part of a URL a browser never sends to any server. Open it and the page auto-generates the reply link, offer-in-fragment the same way. If both clicks happen in the same browser, the reply tab hands the answer to the still-open invite tab over a same-origin BroadcastChannel and the connection completes in two clicks. Different browsers, paste the code. Two clicks or one paste, one connection.
Or just point the phones at each other
A 175-character payload also fits comfortably in a QR code, which enables the pleasingly analog version: the sender's page shows the invite as a QR; the recipient points their camera app at it, which opens the reply page; that page shows the answer as a second QR; the sender taps Scan reply, which opens an in-page camera preview and feeds the decoded answer straight into the pending connection. Two phones staring at each other, and then a file is moving between them over an encrypted channel that no infrastructure of any kind helped set up. Decoding uses the browser's native BarcodeDetector where it exists and a bundled decoder where it doesn't (Safari); both QR libraries are vendored into the single ~360 KB HTML file, so there are no CDN dependencies to be down. A screen wake lock keeps the display lit while a code is showing or a transfer is running.
What you gain, what you lose
Against the ATProto version: connection setup is as fast as the humans, not a 3–10 second polling dance. Nothing public exists anywhere — no signal records for an observer to correlate, no metadata trail, no identity attached. And you no longer need to know the other person at all: no DID, no handle, no account on either side. Anyone who can see your QR code or receive your link can connect.
Which is the trade, stated plainly. The ATProto version authenticated peers by their repos; here the trust boundary is whatever channel carried the code, and nothing else. That's fine — it's the same trust model as handing someone a USB stick — but it means the discipline is yours: the invite contains your machine's network addresses, so only extend it to people you'd tell your IP address, and don't accept files — or candy — from strangers. FileDrop enforces the mechanical half (every incoming file must be explicitly accepted before a byte flows, and everything is SHA-256 verified on arrival); the judgment half is you.
You also lose discovery and reconnection. There's no identity to dial back; every session is a fresh exchange, and both humans have to be present for it. That's not a bug so much as the shape of the thing — this is the protocol equivalent of a handshake, not a phone number.
Limits, honestly
"No server at all" carries one asterisk: by default the browser asks a public STUN server for its outside address, one UDP round-trip that carries no content and learns nothing but that you asked. On a shared LAN the mDNS candidates usually suffice, and #nostun in the URL removes even that. The other limits are the browser's: received files assemble in memory, so the 2 GB cap is theoretical on a phone — mobile Safari's per-tab ceiling makes a few hundred MB the practical limit — and it's one peer per page, by design.
It's a single view-source-friendly file at austegard.com/fd. The packed-SDP format is 130 bytes with room to argue about; if you can get it smaller, I'd like to see it.
Postscript: signaling over sound
Two days after this posted, FileDrop grew a fourth way to pass the setup code: audible sound. The invite page plays the packed offer as about five seconds of tone; the other device listens on its microphone, decodes it, and answers — by sound again, or by link, paste, or QR. All four channels interoperate, so any mix works: invite by sound and reply by QR, invite by link and reply by sound, whatever the two devices in front of you can manage.
It’s the same idea as the rest of the page. The offer is already small — around 130 bytes — so it fits in a URL, a clipboard, a QR square, and now roughly five seconds of audio: four-tone chords in a 4.5–7.3 kHz band, a pilot tone to lock timing, Reed–Solomon coding and a CRC-16 checksum so a mangled decode fails outright instead of connecting to noise. The file’s bytes never touch the speaker — only the setup code does; the transfer itself stays on the WebRTC data channel.
Direction reuses the QR split: a one-character tag rides in front of the code — O for invite, A for reply — and the listener routes O to the answer path and A to apply-the-answer, so the microphone never needs to know which side of the exchange it’s on.