Isn’t https://wormhole.app/ the solution here? Note I haven’t used it, it’s just often brought up here as a good solution for this class of problem. Is it surprising that the author mentions a ton of solutions but not this one? I would think a deep dive of file sending applications would include this, it’s old enough and well known enough in circles that its exclusion in a comparison of file sending approaches does feel like a bit of an oversight
Here is a list of open source options. This isn't the first time I have shared this on here either. Perhaps this is another sign that web search is failing us.
I've tried using Wormhole and Filepizza from two devices on my network (a MacOS laptop and a Windows PC) and they just don't work for me. I assume the others use the same approach, and would probably also not work. I'm sure there's some setting I could change on my home network to make them work, but I think the point of the article is that we're looking for a way that a) just works, b) across platforms, c) even if you're a dummy like me.
I have used many of these to send files from windows to linux or mac to windows. My point isn't that one of the solutions above is perfect, but that the problem has been tackled in a user friendly way with existing web technologies in a variety of ways. These are very small, often one man projects, compared to something like airdrop for example, and they do 80% or more of what you need them to.
I spent less than a minute searching and found another WebRTC based project.
Imagine what could be built with an actual investment? I don't think the money exists for this type of tech, otherwise we would've seen someone do it in the last 20 years.
Just a sanity check: Did you turn off WebRTC and forget that you did? If you're using Firefox, setting both of the about:config flags "media.peerconnection.enabled" and "media.navigator.enabled" to false disables WebRTC.
UBlock Origin's "Prevent WebRTC from leaking local IP addresses" setting also might interfere even though I don't think it turns WebRTC off. The same applies to Brave's "Disable non-proxied UDP" option for the "WebRTC IP handling policy" setting.
a) Connection from one port of your external IP address to another port on your external IP address will not work if you are behind NAT that is not set up properly to enable hairpin connections.
b) Local IP addresses to connect to may not be provided by the browser to the Javascript code if there's a setting or extension that disables it.
c) Local router can be set up to prohibit traffic between clients (usually wireless devices). If hairpins don't work, you can't exchange any data between such devices without the help of external relay server, as there is no local network at all.
Other than that, WebRTC promises that two browsers can transfer data directly if they are able send UDP packets to each other somehow.
There is also Send.Vis.ee, which is a community fork of Firefox Send. It has always worked very well for me personally. There are many public instances available with varying file size limits and expiring conditions.
Nice thanks. I think the exclusion of some of these is especially egregious because the author identifies three criteria and then says that none of the solutions they explored fully meet all three. But at least from an early glance at least one or two of the solutions you mentioned do, as well as the solution I linked. Which kind of invalidates the entire point the article was trying to make, that there are not good solutions for this. There are, the author just didn’t consider them.
I have used all of these solutions, including the one you shared in the past.
Some of them used to work better than they do now, I imagine with browsers updating and the software going unmaintained, it hasn't left them in a great state. These are small open source projects without funding from what I can tell.
The fact that they work at all is amazing to me, and says a lot about what we can do with a few Web APIs. If only it was worth getting these individuals to collaborate on a web standard API around file transfers, maybe then we would finally see a long-standing solution.
None of them work like Airdrop or Nearby Share. You can't right click a file in the file explorer on PC or Mac and share it. Nor you can open a photo on your mobile photo app and chose share.
The downside of websites like that is that it travels over the internet, so you're throttled by every bottleneck along the way, which can be very painful if you're out and about and your hotspot is suffering 3G speeds. Meanwhile, Airdrop spawns an ad-hoc network giving you gigabit transfers in the middle of nowhere. Personally, if Airdrop isn't an option, I use TotalCommander to transfer over my hotspot network (no internet connection needed)
Not so for WebRTC. We use Snapdrop all the time to transfer between devices, and it just gets the two nodes talking, but the data xfer is peer to peer on our network. Works great.
I don't think a browser is involved with the solution either. The protocol/transport definitely isn't the problem. It doesn't matter. The problem is integration, and solution, is integration.
The tricky bit that makes this hard is discovery. I think Apple does it right. UDP multicast discovery across local intranet, with bluetooth broadcast/NFC proximity for physically near devices that might be on separate networks/locked down. There's the possibility of internet based discovery, but that involves a central authority keeping track of your IP, constant polling, with a nice record of all your devices and transactions. In China, there are apps that use audio, for local discovery, which is neat.
I firmly believe we won't ever have a real solution for the next 30 years. It would require three enemies cooperating: Android, Microsoft, Apple. As is, Apple has this solved. Samsung is gettin there. Microsoft has nothing.
