How it works

0. Why this is true P2P (not "AirDrop for the web")

Tools like AirDrop, LocalSend, and Snapdrop only work between devices on the same local network. FileTransferNow uses WebRTC — the same technology powering Google Meet, Discord voice, and Whereby — so it works between any two browsers on the public internet, no matter what network each side is on.

Sender on home WiFi in Mumbai, receiver on coffee-shop WiFi in Berlin? Works. Sender on 5G mobile, receiver behind a corporate firewall? Works. Same machine, two browser windows? Also works. The signaling server only helps the two browsers find each other — the file itself flows directly browser-to-browser, encrypted end-to-end.

1. The signaling handshake (the only server moment)

WebRTC peers can only talk to each other once they've exchanged session descriptions (SDP) and ICE candidates. A lightweight WebSocket server — the only piece of cloud infrastructure in the system — acts as a temporary mailbox for these small text messages. It sees the metadata needed to set up the connection, never the files.

Once both peers have an open RTCPeerConnection, the signaling channel goes idle. From that point on, the two browsers talk directly to each other. Even if our signaling server went offline mid-transfer, the file would keep flowing.

2. NAT traversal — how browsers find each other across networks

Most home and office routers hide their devices behind NAT (Network Address Translation). Two browsers behind different NATs can't just connect by IP — neither knows the other's public address, and routers reject unsolicited inbound packets.

WebRTC solves this with two protocols:

• STUN — a tiny query ("what's my public IP?") to a public server like stun.l.google.com. Works for ~85% of home networks. The STUN server sees nothing about your files, only your IP.
• TURN — fallback relay for the trickiest networks (symmetric NATs, locked-down corporate firewalls). We pull short-lived TURN credentials from Cloudflare's free TURN service so even strict networks work. The relay sees DTLS-encrypted ciphertext — never plaintext.

Together these give us ~99% connection success across real-world networks. If both endpoints are unreachable, you can fall back to paranoid mode and exchange the SDP handshake manually (e.g. paste into Signal).

3. Secure UDP transport with DTLS

WebRTC data channels run over SCTP on top of DTLS. Translation: encrypted by default, NAT-traversing UDP. There is no opt-in step for encryption — if a data channel is open, it is end-to-end encrypted. The encryption keys are negotiated directly between the two browsers and never leave them; not even a TURN relay (if used) can decrypt the stream.

const peer = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
const channel = peer.createDataChannel('file-payload');
channel.binaryType = 'arraybuffer';

4. Streaming 100GB without crashing the browser

Naively reading a 100GB file into memory is a one-way ticket to a browser crash. We use the File.stream() API to pull the file in chunks, ship each chunk over the data channel, and pause when the outbound buffer fills up.

const CHUNK_SIZE = 16384; // 16 KB — WebRTC's friendly default
const reader = file.stream().getReader();
while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  if (channel.bufferedAmount > channel.bufferedAmountLowThreshold) {
    await new Promise(r => channel.onbufferedamountlow = r);
  }
  channel.send(value);
}

5. Writing to disk with OPFS

On the receiver side, each chunk goes straight to the Origin Private File System — a per-origin sandboxed disk that browsers expose via navigator.storage.getDirectory(). OPFS is fast (no IPC roundtrip) and durable, so RAM stays flat even mid-100GB transfer. Bonus: if the connection drops, we can resume exactly where we stopped instead of restarting from byte 0.

const root = await navigator.storage.getDirectory();
const draft = await root.getFileHandle(meta.name, { create: true });
const writer = await draft.createWritable();
await writer.write({ type: 'write', data: chunk, position: offset });

6. Architectural flow

7. Edge cases we handle

• Symmetric NAT / locked firewalls: Cloudflare TURN relay kicks in automatically. If even that fails, we surface a fallback message and offer manual SDP exchange.
• Background-tab throttling: Screen wake-lock keeps the display on; we also warn the user when the tab goes background so they know transfer may slow until they refocus.
• Silent peer stalls: Application-level heartbeat detects when the other side stops responding (within ~15s) — faster than native ICE timeouts — and force-reconnects.
• Mid-flight drops: Transfer resumes from the last on-disk byte instead of restarting from 0. Adaptive reconnect timeouts (up to 90s) cover slow TURN renegotiations.
• OPFS quota: we call navigator.storage.estimate() before any write and garbage-collect stale partials after 7 days.
• Paranoid mode: skip the signaling server entirely — manually paste the SDP offer and answer between peers.