The problem
I wanted a way to get a file off a shared machine (or move one between devices) without logging into my accounts, e.g. a conference room PC before a talk, or any computer you don’t own. Signing into email or cloud storage on those machines is something I actively avoid.
I also didn’t want to upload everything to the cloud by default when local connectivity was enough. If the bytes can stay on the LAN or go peer-to-peer, that’s preferable to “ship it to a third party and download it again.”
Why WebRTC
WebRTC fit because it’s open, well-supported in browsers, and can establish direct transfers when the network allows, with no bespoke desktop install and no vendor lock-in for the transport story. The app is a React / Next.js shell with serverless glue on Vercel for signaling; the heavy lifting is browser-to-browser when the path is clear.
This started as a learning project. The goal was to understand WebRTC in practice and actually ship something usable, not to build a production-grade system.
When it works
On a good path, it’s tuned for low latency (sub-250ms happy path) and large files (10+ GB in real-world use at gigabit-friendly speeds), which is faster and more private than routing through a generic upload bucket when P2P actually connects.
Drawbacks & what I’d do differently
One-to-one, not one-to-many. Scaling to broadcast-style distribution isn’t the model; it’s a direct pipe between two peers.
Corporate and locked-down networks are the real enemy: many environments block or cripple WebRTC, lean on UDP-unfriendly paths, or proxy everything, so reliability is nowhere near “works everywhere like a cloud link.” The blunt truth: for maximum compatibility, upload to Drive and shorten the link is often the path of least resistance.
If I rebuilt it today, I’d think harder about fallbacks (explicit relay/TURN costs, optional small-file server path).