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. WebRTC is the default path: if both browsers can reach each other directly (which works for the large majority of home and office networks via STUN/TURN negotiation), the file streams peer-to-peer, encrypted with AES-256-GCM before it ever leaves the sender's device.

When a direct WebRTC channel can't be negotiated, Srift doesn't just fail — it falls back to a WebTorrent-style chunked transfer, and beyond that, a WebSocket relay. In relay mode, a server sits in the middle, but it only ever handles ciphertext: it relays bytes it cannot decrypt, rather than storing or reading the file.

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 fallback (sometimes called a TURN server in the WebRTC world) becomes necessary: instead of connecting directly, both sides connect to a relay and it forwards traffic between them.

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 standing download link instead of requiring a live session.

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.