Peer-to-Peer File Transfer, Directly In Your Browser

Most file-sharing tools are client-server: you upload to a company's servers, and the recipient downloads from those same servers. Peer-to-peer flips that — the sender's browser and the receiver's browser open a direct connection to each other, and the file streams across that connection without a third-party copy in between.

In the browser, this is built on WebRTC data channels — the same underlying technology used for video calls, just carrying file chunks instead of audio/video frames. Two browsers exchange connection information (a process called signaling) through a lightweight coordination server, then open a direct channel once they've found each other.

Create a session at /create-session, share the session ID or QR code, and the other person joins from /join-session. The browsers first try a direct WebRTC data channel, using public STUN servers and short-lived TURN credentials, and give it about three seconds to open. If it opens, the file streams peer-to-peer, encrypted by WebRTC's mandatory DTLS between the two browsers. The step-by-step mechanics are in how P2P file transfer works.

When a direct WebRTC channel can't be negotiated, SRIFT doesn't just fail — it falls back to a WebSocket relay. In relay mode, a server sits in the middle, but it forwards ciphertext instead of storing the file: each chunk is sealed with AES-256-GCM under a fresh key the two devices agree on for that transfer (ECDH P-256 + HKDF-SHA256), and the server only handles their public halves. If the direct channel drops mid-transfer, the relay continues from the bytes already received. If a network blocks WebSockets entirely, the browser switches its connection to a plain HTTPS stream and keeps going.

Why the layered fallback matters

Real networks are messy. Symmetric NAT, corporate firewalls that block UDP, and captive portals on public Wi-Fi can all prevent a clean WebRTC handshake. A P2P tool that only supports the "happy path" simply fails on those networks. SRIFT's fallback chain trades a small amount of latency for reliability when the ideal direct path isn't available.

Almost every device on a home or office network sits behind Network Address Translation (NAT), meaning it doesn't have a publicly routable IP address of its own. For two browsers to open a direct connection, each one needs to discover its own public-facing address and punch a hole through its router's NAT — a process WebRTC handles using STUN servers, which simply tell a device what its own public IP and port look like from the outside.

Most home routers use a NAT type that allows this hole-punching to succeed on the first try. Some networks — particularly larger corporate networks and certain mobile carrier configurations — use symmetric NAT, which changes the external port for every new connection attempt and defeats simple hole-punching. That's precisely the case where a relay becomes necessary (a TURN server in the WebRTC world): instead of connecting directly, both sides connect to a relay and it forwards traffic between them. NAT traversal explained and STUN vs TURN go deeper.

Live P2P sessions are a good fit when both people are online at the same time and want the fastest, most direct path — a designer handing a large video export to a client on a call, or two developers swapping a build artifact during a pairing session.

They're not the right fit for asynchronous sharing, where the recipient might grab the file hours or days later. For that, use srift quick-share <file> from the CLI, which produces a download link instead of requiring a live session. The file still isn't uploaded: it streams from your machine through the relay when the link is opened, so keep the CLI running until the recipient has downloaded it (--wait exits once they have).

It's also worth being clear that P2P isn't automatically the fastest option in every scenario. If both peers are on the same fast local network, a direct WebRTC channel is close to unbeatable. But if one side has a slow upload connection, no amount of protocol cleverness changes the fact that data can only leave that device as fast as its uplink allows — P2P removes a hop, it doesn't remove physics.