I built AirDows, a browser-based tool for transferring files between devices using WebRTC.
The idea is simple: open AirDows on two devices, connect them using a QR code or temporary PIN, and send files without creating an account or uploading them for later download.
AirDows attempts a direct peer-to-peer connection first. If the networks cannot establish a direct route, it uses an encrypted TURN relay. The files are not stored by AirDows.
It currently supports:
- Transfers across different networks - QR code and temporary PIN pairing - Direct-to-disk writing in supported browsers - Compatibility mode for other browsers - Large-file transfers - Transfer queues, cancellation, and resume support - PWA installation
It is an early free beta, so both devices need to remain active and performance depends on the browsers and network route.
I would appreciate honest feedback on reliability, privacy, the pairing flow, and large-file transfers.
Thanks for that mental exercise.
There are no reliable, fast AND free TURN servers (IMO), and even semi-private relays can quickly become overwhelmed or too costly to operate.
warpgate.io
Like Bump did before it was shut down by Google.
<https://hn.algolia.com/?dateRange=all&query=peer%20file%20sh...>
That's why WebRTC supposes that the service provides some TURN relays from the start, and any commercial application comes with its own relays or uses third party infrastructure. That's why when you see any mention of “peer-to-peer” in this context, it actually means “which percent of monthly traffic on average we can offload”.
Notice that those are stats for unique data transmissions between one user and another. When data is not unique (same live video segments to many users), we can have one-to-many sharing, and the percentage of offloaded data can grow much more. Candidate selection for reliable seeding role is non-trivial, though, and it might only make sense when the swarms are big enough to contain enough peers that accept incoming connections.
As other said, quite a lot of those services exist. When they don't provide TURN servers, they have questionable utility (but can be used in the same local network). When the author does host a server for others, you obviously don't want to shove gigabytes of data into it (and the safe bandwidth limit is usually too slow for that anyway). Network connections do not seem to be the main problem, writing the client code properly, and in a way compatible with multiple browsers and unexpected events does.
If you have a non-recurrent need to transfer some data, and no server at hand, Syncthing volunteer-run relays seem to have some capacity available.
So many of these tools just silently fail. And there's so many of them!
But i just tried it in zen browser on fedora 44 and the system hard locked up. I guess I could try chromium next time.