I built a browser-based P2P file transfer tool using WebRTC

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.

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.

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

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.

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