https://gist.github.com/SMUsamaShah/fd6e275e44009b72f64d0570... I keep a handy list. Does this stream file directly to disc or keep it in browser cache or memory? In this list I think only web wormhole does that which means it should be able to transfer huge files without any problem. Most tools crash if files are in GBs.
I went down the list a couple weeks to go trying to move files from my windows desktop to my Chromebook and the only thing that worked in the top 5 or 10 was localsend.
So many of these tools just silently fail. And there's so many of them!
You have some web page material in English, and some material in either Spanish or Portuguese. You might want to check everything twice before posting on HN.
Not the poster but I had to go check the website to see this. I believe it is in Spanish. It makes me pretty happy to realize that even though I have had little or no conversations with Spanish speakers for about 30 years I was able to understand the untranslated text. There is so much that clicked once I had the context through the words that I recognized. The rest of it began to make sense.
you're right, AirDows started as a Spanish first beta, and some pages are not fully localized yet, i'm fixing the language consistency before the next round of promotion thanks for pointing it out
I guess this sort of tool provides a good learning experience for developers or implementing one scratches some other itch, because there are so many one here:
Does anyone know what the actual success rates for webRTC are for like different NAT combinations / nodes in the wild? I'd be curious, I have read a little into it myself but didn't get the feeling it was very flexible compared to something like Tailscale.
It depends on applications and users (home, mobile, corporate). Some anecdotal evidence suggests that 2/3rds of user pairs can't connect without a relay server with all the tricks deployed (NAT traversal, IPv6 when available, client side port guessing for certain predictable NAT implementations), in other case it is 9 out of 10, or almost everyone. However, if you and your friend can't connect, what are the benefits of knowing that 100 other users succeeded?
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.
Hi, I built a plugin-based P2P socket system from scratch that supports TCP punch, UDP punch, random probe, TURN, and other such systems. It includes a full stack from networking, signalling, and naming, all based on open infrastructure. It's open source and licensed under MIT:
Bandwidth costs money not to mention if it was truly free it would probably be an abuse vector. Cloudflare offer 1000Gb free per month - https://www.cloudflare.com/products/turn-sfu/ and pricing beyond that isn't bad either.
thats one of the main operational challenges. AirDows attempts a direct connection first and only uses TURN when NAT conditions require it. I'm already measuring relay usage and evaluating sustainable TURN providers and limits while keeping the beta free...
Thanks, bluetooth-based file transfer is not reliable enough across modern web browsers, especially on iOS, i may explore Bluetooth for nearby device discovery in a future native companion, while keeping WebRTC as the actual transfer channel
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.
https://gist.github.com/SMUsamaShah/fd6e275e44009b72f64d0570... I keep a handy list. Does this stream file directly to disc or keep it in browser cache or memory? In this list I think only web wormhole does that which means it should be able to transfer huge files without any problem. Most tools crash if files are in GBs.
I went down the list a couple weeks to go trying to move files from my windows desktop to my Chromebook and the only thing that worked in the top 5 or 10 was localsend.
So many of these tools just silently fail. And there's so many of them!
Thanks for keeping the list going. I link to it on here now and again.
You have some web page material in English, and some material in either Spanish or Portuguese. You might want to check everything twice before posting on HN.
Not the poster but I had to go check the website to see this. I believe it is in Spanish. It makes me pretty happy to realize that even though I have had little or no conversations with Spanish speakers for about 30 years I was able to understand the untranslated text. There is so much that clicked once I had the context through the words that I recognized. The rest of it began to make sense.
Thanks for that mental exercise.
that's genuinely nice to hear. Thanks for taking the time to explore it despite the language mismatch, a consistent English version is coming
Keep up the good work!
you're right, AirDows started as a Spanish first beta, and some pages are not fully localized yet, i'm fixing the language consistency before the next round of promotion thanks for pointing it out
I guess this sort of tool provides a good learning experience for developers or implementing one scratches some other itch, because there are so many one here:
<https://hn.algolia.com/?dateRange=all&query=peer%20file%20sh...>
[flagged]
Does anyone know what the actual success rates for webRTC are for like different NAT combinations / nodes in the wild? I'd be curious, I have read a little into it myself but didn't get the feeling it was very flexible compared to something like Tailscale.
It depends on applications and users (home, mobile, corporate). Some anecdotal evidence suggests that 2/3rds of user pairs can't connect without a relay server with all the tricks deployed (NAT traversal, IPv6 when available, client side port guessing for certain predictable NAT implementations), in other case it is 9 out of 10, or almost everyone. However, if you and your friend can't connect, what are the benefits of knowing that 100 other users succeeded?
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.
Hi, I built a plugin-based P2P socket system from scratch that supports TCP punch, UDP punch, random probe, TURN, and other such systems. It includes a full stack from networking, signalling, and naming, all based on open infrastructure. It's open source and licensed under MIT:
warpgate.io
What happens when TURN is inevitably needed? Many people are behind something like CG or symmetrical NAT with no direct way to talk to each other.
There are no reliable, fast AND free TURN servers (IMO), and even semi-private relays can quickly become overwhelmed or too costly to operate.
Bandwidth costs money not to mention if it was truly free it would probably be an abuse vector. Cloudflare offer 1000Gb free per month - https://www.cloudflare.com/products/turn-sfu/ and pricing beyond that isn't bad either.
thats one of the main operational challenges. AirDows attempts a direct connection first and only uses TURN when NAT conditions require it. I'm already measuring relay usage and evaluating sustainable TURN providers and limits while keeping the beta free...
I have a similar app https://wportal.app :)
How is it different from https://copypaste.me/ ?
I love this idea.
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.
Looks great. How long until it does P2P via Bluetooth?
Like Bump did before it was shut down by Google.
Thanks, bluetooth-based file transfer is not reliable enough across modern web browsers, especially on iOS, i may explore Bluetooth for nearby device discovery in a future native companion, while keeping WebRTC as the actual transfer channel
Hi HN,
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.