Writing code is fun, but I can't find much of a downside with Bluetooth here. "You can accidentally turn it on" (fair, I guess?) "and it drains battery like crazy" (it shouldn't unless you have a very buggy device) don't seem like that bad compared to Yet Another File Sharing App.
I remember way back in the Android 4 era, my phone and my tablet both supported some "standard" form of WiFi Direct. It worked intuitively (just share a file), was blazingly fast (as fast as P2P WiFi can be), was low latency, and just worked. I used it to transfer media files and backups and it easily beat having to hook up a USB cable to two devices. I was sad to find out this was probably some kind of proprietary interface, because the feature seems to have vanished. It was the best local file sharing mechanism I'd ever used and it disappeared into thin air. Android Beam was nice, but computers and tablets don't have the required NFC hardware to make it work.
I don't expect Apple to play nice with anyone else, but it's time Microsoft, Google, and the various Android manufacturers got their shit together and developed some kind of open sharing system. Google and Samsung already joined forces, but Microsoft seems to have gone off to do their own thing again. We have P2P WiFi for display sharing and the like, why can't we decide on some kind of file sharing protocol here? I don't care if it's SMB or FTP or HTTP, it's really not that difficult a problem to solve. The only issue is that there are hundreds of apps, each with their own protocols and implementations, none of which come packaged with the OS.
Yes, this is killing me. I have a colleague that told me "on iPhones I can super easily share files to someone else", and I'm like "20 years ago sharing files across devices was a non-issue, because we had STANDARDS (ok maybe 17-18 years ago rather). Sharing files wasn't considered a feature worth mentioning because every phone supported this out of the box (well not exactly, so the feature was having Bluetooth). Tech monopolies prefer to ignore standards (looking at who implements which parts of Matter is pretty hilarious in that regard), and killed a whole range of obvious things in the process.
As much as I hate Apple for their repetitive NIH syndrome, Bluetooth has never worked flawlessly, and increasing filesizes made it increasingly maladapted.
> Writing code is fun, but I can't find much of a downside with Bluetooth here.
Yesterday my son needed to transfer a video file from his Android phone to his school iPad. We tried Bluetooth, but it simply kept failing, no matter what we tried. The devices saw each other and could be paired, but file transfer didn't work at all. We tried sending the same video file to another Android phone, and it just worked on first try.
So, even basic Bluetooth doesn't work in all cases, unfortunately. He ended up recording a video of his phone playing the video... :)
> I don't expect Apple to play nice with anyone else...
This seems to be the problem in our case.
Tonight I'll setup a Nextcloud on our network, this should work properly.
I wrote a similar comment but so far have only received downvotes without any feedback as to why people seem to disagree with me. Admittedly, maybe my position is a bit more extreme, in that I think it would be pretty reasonable to consider applying political pressure or even legislating to improve file sharing and interoperabiliy between devices. I'd prefer it if big tech companies would just come together and implement support for full cross platform file transfers, but I don't see that happening.
My biggest frustration is that there doesn't seem to be anyone with a large platform willing to ask people in leadership at the big tech companies about such features.
In my ideal world: big tech would come together to write some spec, then devices and operating systems would slowly implement and roll it out. And on older devices you could just build a third-party app that implements the same functionality. The goal would be that ultimately you'd have seamless basic interoperability between devices without having to install third-party apps.
Bluetooth is really slow, that's the main drawback.
WiFi Direct is a really great technology but unfortunately it is as simple as its name implies: it's a peer-to-peer version of WiFi. It establishes a connection between two devices, but you need to do everything else (like figuring out how to send files over the socket) yourself.
There are plenty of cross-platform apps that implement WiFi Direct file sharing though.
What I find weird is how easy to use is (was?) Wi-Fi Direct between Android phones and how this isn't a common thing in Windows or other non-mobile OSs.
I have just Discovered Windows 10 have Wi-Fi Direct if you have both Wi-Fi and Bluetooth adapters, and it's as easy as enabling it and right clicking a file to share it. It's a shame this isn't common knowledge nowadays
Microsoft's Nearby Share isn't the same as Android's Quick Share (formerly Nearby Share). You can download an app to get Google's share feature working, though, but that doesn't fix the problem.
The best solution I have found to easily exchange files between devices so far is to use Telegram. It works perfectly for your own devices.
You can have it on multiple devices at the same time (computers, phones,...), there is a special "saved messages" channel for files, it can easily accommodate small to reasonably big files (like GB files), and there is also a webclient that you can use in a few seconds if you are not on your trusted computer.
You can also delete the file once you are done.
The only problem is that you will have to trust Telegram for having you data. But I guess that if you are ready to trust WeTransfer or Google drive, it is not really different.
Yeah same here. Feels stupid sometimes though to transfer a 2GB file from my pc to my laptop through Telegram's servers when I could do it in my LAN but nothing has beaten Telegram's UX for me so far so I always wound up using it.
Taildrop just solve a smaller part of the problem space.
For example, often the target might not be up or connected and you might want to have your file available to all your devices.
The closest competitor to Telegram in term of convenience is email I think.
Just a common use case, I will be at work, and will get a airplane eTicket pdf for a business trip.
I would connect through telegram web to drop it into my saved messages. Then, later I would be quite sure to have it available on any of my phones when being at the airport, and even being able to access it from my personal laptop later for a visa request for example.
Also, a moment later, I could suddenly share it with my girlfriend so that she have all the info to pick me up when I will come back.
In addition I can quite easily search such documents by keywords or date.
The hilarious thing is that was what Dropbox was meant to solve.
Like Drew Houston's demos to Y Combinator was copying a file to a given folder on one computer... and seeing it show up in the corresponding folder on another computer. HN comments at the time were dismissing, like "whatever, I can do that with rsync"
I hate how it's gotten progressively harder as the big platforms effectively declared war on local files. Tools like ES File Explorer and WinSCP used to work great, once upon a time.
It is purely because of the lack of static addressing. Probably an entire country's GDP-worth of SaaS products are essentially nothing more than providing basically a proxy to other devices that have to have apps installed to speak their special language.
If I knew your computer's address (and it didn't change) and you knew mine, we could route traffic through the infrastructure we already pay for.
If only we had something like AirDrop that reliably worked cross-platform.
Proximity-based sharing just makes significantly more sense than uploading files to some server miles away, then immediately redownloading them back when the computer was two feet away from you the whole time.
Pairdrop was posted on HN a little while back and I setup an instance on my home network. Doesn't work everywhere obviously but it does seem to effectively solve this problem within my household.
Syncthing tries to send over the LAN if it's available, and only uses Internet relay servers if it can't establish LAN connectivity. This is why it's (usually) blazing fast. Not sure why the OP thinks this is a misuse of the tool. In fact, it's probably one of the intended purposes of it.
Yep, syncthing is the closest I've found to a simple(ish) cross platform solution. Though when at home, my actual solution is to copy to my file server on one device, then copy from the server on the other.
I regularly have to send files to customers, from a few megabytes to a few gigs. It's incredibly hard.
Mail? Goes to spam.
WeTransfer? Mail clients break URL.
Download from my website? Some stupid browser will display the zip data onscreen.
Send the link through messenger? Messenger breaks the link.
SaaS gallery? Some file managers can't open the zip file.
I've been doing that for two years now. Still don't have a 100% working solution. It drives me mad. Just yesterday I spent 30 minutes sending 3 jpeg files to a customer.
Most webservers have a way of adding a header# Content-disposition "attachment; filename=$1"; that forces downloads. Nginx at least guesses based on file extension / mime type.
FYI - I've also recently run across end users who are likely victims of overzealous IT departments that disable Basic Auth, even on HTTPS connections. Even though they don't do anything to form fields which might contain the exact same data. I don't mind if they break their own domains but the whole Internet?
Oh no, I've seen Chrome and Firefox (with a well-conforming web server) loading zip files as if they're pages. The culprit? Intercepting HTTPS-breaking inspection. This is not just in enterprise environments, antivirus companies somehow even justified "HTTPS scanning" as a feature.
in the mid 90s i worked in a machine shop that had a side business where they had catalogs. They were trying to send .TIFF files over 14.4 or 28.8 modems. TIFF files over 10MB, so no floppy (easily.) No CD-R, Jazz/zip.
These days in the same circumstance as you (and they) had, i'd fedex them a USB stick, or optical disc, depending. Because the first time someone said "the web page you linked is just displaying garbage" i'd turn in my tech credentials, because that's probably my server's fault, not the browser. MIME has been a thing for three decades, at least. it sounds like someone tried to use a static html daemon to share a zip file, and it assumes everything is ascii. like it's 19xx and zmodem hasn't been invented yet.
Nextcloud works well for this, and as the files are already on your server you don't have to upload anywhere, you just share the folder, put an expiry date on and send them the url
To add to this, it's reasonably easy to run, and has many different plugins, from a calendar and contacts list, to an online document editor (like Google Docs, except it can be pretty slow and/or resource intensive: https://nextcloud.com/office/), to a simple clone of Slack (https://nextcloud.com/talk/), a mail client (https://apps.nextcloud.com/apps/mail) and other things.
That said, I've had updates (across major versions) break things on multiple occasions, one out of two servers running the exact same version has random crashes and in addition to that the file locking by default (if enabled, but not using Redis: https://docs.nextcloud.com/server/latest/admin_manual/config...) has broken and prevents me from deleting a file that just sits there and takes up a few GB of space. Oh and their Android app fails to upload files if I use the share option, instead of the file picker from within the app.
On the other hand, sure beats storing data on third party clouds and is free, so I'll still keep using it.
I had explored the opportunity [1] to help send files securely based on the Firefox Send fork available at [2]. It proved very difficult to sell with actually no interest in such a product (and I probably sold it the wrong way).
I still use it myself and never had links not usable by the recipient (shared by mail).
I don't have a good asynchronous solution, but if you can do it while on the phone/Teams with them, then Web Wormhole (https://webwormhole.io/) is absolutely fantastic. You both open a web page, you drag a file onto yours and it starts appearing in their download folder.
It's WebRTC based so peer-to-peer, E2E encrypted, with servers only used for serving the client, and for NAT punching.
What you really want is the native iOS or Android version of this (or of any Magic Wormhole derivative), which the wormhole-william people are working on (I think the Android version already works).
I tried wormhole.app many times and have about a 60% failure rate because there's an error or the download never completes. Don't know the difference with your link but i suppose i should try it next time
That would be blocked in a lot of large companies. IT blocks common cloud storage urls to prevent employees from storing company data on third party servers.
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.
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.
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.
For this I created a public Backblaze bucket, created a lifecycle rule that deletes files after 7 days, created an application key with write privileges but not read ones, then wrote a script that uploads an arbitrary file under a random name so only people with the name will be able to download or overwrite it. The best part is that the file is available under an HTTP direct link, not behind an obscure webpage with ads, so it’s easy to deal with with any tool and doesn’t require the other end to install WhatsApp or Telegram etc, and there is no file size limit (you pay $1.5/TB but it’s fairly cheap if you deal mostly with files <1GB). Now I just wish I could write such a script for my mobile phone as easily.
Now this violates rule #1 (you need an account and you need to pay $6/TB/month for files stored, or $1.5/TB if you store files for only 7 days). For rule #4 you can set the lifecycle arbitrarily, like 1 day, such that the cost of storage is less than the cost of traffic.
No need to give your file an obscure name, or use a public bucket. You can use a private bucket and create a presigned URL with an expiration of up to one week.
Presigned URLs are long and ugly and b2 requires an extra API call to generate that, so I tend to prefer not to use them. The other reason for obscure names is so that you can't download or update files that you don't know the name even if you have the upload key. I know it goes against common sense security practice but compromising convenience can mean compromising security in many cases. The thing is to make sure your scheme is rigourous.
I recently started using KDE Connect because I was fed up with the way I had to send photos from my Android phone to my Ubuntu desktop. I usually did that by email, or in some rare cases I plugged a USB cable in to connect.
KDE works over Bluetooth, I guess, but it was super fast for transferring around 20 to 30 photos at the same (maybe more might also work, didn't try that).
But the most important thing was that I could look at the thumbnails of the photos before marking them for transfer. This process was always very slow with an USB connection, because it was always trying to 'thumbnailize' every photo in the folder (which were 100s or 1000s). Picking the right photos by obscure datetime-name is not fun.
That's the #1 solution for devices under my control.
For the rare cases, where I need to transfer personal data to/from corporate devices, I just use https://webwormhole.io/
On windows I had to explicitly allow the executable in the windows firewall. I didn't get any popups or warnings that it got blocked. After that, it worked fine
Tailscale recently added local file transfers called Taildrop https://tailscale.com/kb/1106/taildrop
This really solved this issue for me, right click a file and select the receiving peer and it just appears instantly on the other device.
I would assume that limitation is because it's on the roadmap, but they want a different UI for it, or more control, or to see how beta goes with just your own devices, give some time to think about how it should work, etc.
Because they've had to specifically put that limitation in place, no way they don't realise it could be useful.
I created an automated installer to provide this functionality on KDE Plasma using Dolphin this morning to emulate the experience of sharing via TailDrop on Mac for Linux.
Readit News
I remember way back in the Android 4 era, my phone and my tablet both supported some "standard" form of WiFi Direct. It worked intuitively (just share a file), was blazingly fast (as fast as P2P WiFi can be), was low latency, and just worked. I used it to transfer media files and backups and it easily beat having to hook up a USB cable to two devices. I was sad to find out this was probably some kind of proprietary interface, because the feature seems to have vanished. It was the best local file sharing mechanism I'd ever used and it disappeared into thin air. Android Beam was nice, but computers and tablets don't have the required NFC hardware to make it work.
I don't expect Apple to play nice with anyone else, but it's time Microsoft, Google, and the various Android manufacturers got their shit together and developed some kind of open sharing system. Google and Samsung already joined forces, but Microsoft seems to have gone off to do their own thing again. We have P2P WiFi for display sharing and the like, why can't we decide on some kind of file sharing protocol here? I don't care if it's SMB or FTP or HTTP, it's really not that difficult a problem to solve. The only issue is that there are hundreds of apps, each with their own protocols and implementations, none of which come packaged with the OS.
Yesterday my son needed to transfer a video file from his Android phone to his school iPad. We tried Bluetooth, but it simply kept failing, no matter what we tried. The devices saw each other and could be paired, but file transfer didn't work at all. We tried sending the same video file to another Android phone, and it just worked on first try.
So, even basic Bluetooth doesn't work in all cases, unfortunately. He ended up recording a video of his phone playing the video... :)
> I don't expect Apple to play nice with anyone else...
This seems to be the problem in our case.
Tonight I'll setup a Nextcloud on our network, this should work properly.
- https://www.sharedrop.io/
- https://webwormhole.io/
- https://snapdrop.net/
- https://perguth.de/peertransfer/
- https://pairdrop.net/
The iOS version of VLC has a built in webserver you can remotely connect to for file transfers.
You connect to the iPad's IP address with any web browser and then transfer files back and forth.
https://allthings.how/vlc-player-share-files-wifi-iphone-pc/
Deleted Comment
My biggest frustration is that there doesn't seem to be anyone with a large platform willing to ask people in leadership at the big tech companies about such features.
In my ideal world: big tech would come together to write some spec, then devices and operating systems would slowly implement and roll it out. And on older devices you could just build a third-party app that implements the same functionality. The goal would be that ultimately you'd have seamless basic interoperability between devices without having to install third-party apps.
How would this help them coerce people to stay within one vendor's ecosystem? It wouldn't.
>The goal would be that ultimately you'd have seamless basic interoperability between devices without having to install third-party apps.
Interoperability is the last thing that some big tech companies want.
WiFi Direct is a really great technology but unfortunately it is as simple as its name implies: it's a peer-to-peer version of WiFi. It establishes a connection between two devices, but you need to do everything else (like figuring out how to send files over the socket) yourself.
There are plenty of cross-platform apps that implement WiFi Direct file sharing though.
I have just Discovered Windows 10 have Wi-Fi Direct if you have both Wi-Fi and Bluetooth adapters, and it's as easy as enabling it and right clicking a file to share it. It's a shame this isn't common knowledge nowadays
There is one: Quick Share/Nearby Share. It's supported on both Windows and Android.
I think the worse blocker is _piracy_. The copyright predators are terrified about people sharing files locally.
You can have it on multiple devices at the same time (computers, phones,...), there is a special "saved messages" channel for files, it can easily accommodate small to reasonably big files (like GB files), and there is also a webclient that you can use in a few seconds if you are not on your trusted computer.
You can also delete the file once you are done. The only problem is that you will have to trust Telegram for having you data. But I guess that if you are ready to trust WeTransfer or Google drive, it is not really different.
The best option I can think of is syncthing, but the ux for non technical users isn't great.
For example, often the target might not be up or connected and you might want to have your file available to all your devices.
The closest competitor to Telegram in term of convenience is email I think.
Just a common use case, I will be at work, and will get a airplane eTicket pdf for a business trip.
I would connect through telegram web to drop it into my saved messages. Then, later I would be quite sure to have it available on any of my phones when being at the airport, and even being able to access it from my personal laptop later for a visa request for example.
Also, a moment later, I could suddenly share it with my girlfriend so that she have all the info to pick me up when I will come back.
In addition I can quite easily search such documents by keywords or date.
My current iteration is just a "transfer" SyncThing folder that is on all my devices. It's not clean or convenient but at least its incredibly fast.
Like Drew Houston's demos to Y Combinator was copying a file to a given folder on one computer... and seeing it show up in the corresponding folder on another computer. HN comments at the time were dismissing, like "whatever, I can do that with rsync"
And then cloud storage became a thing.
That one has no one but themselves to blame - the developers went for monetization by click fraud.
[1] https://www.slashgear.com/1010495/the-file-explorer-app-you-...
If I knew your computer's address (and it didn't change) and you knew mine, we could route traffic through the infrastructure we already pay for.
Proximity-based sharing just makes significantly more sense than uploading files to some server miles away, then immediately redownloading them back when the computer was two feet away from you the whole time.
Windows, Linux, Android, iOS and macOS. Seems quite cross-platform. Can confirm it works smoothly for Linux and Android at the very least.
https://github.com/schlagmichdoch/PairDrop
Mail? Goes to spam.
WeTransfer? Mail clients break URL.
Download from my website? Some stupid browser will display the zip data onscreen.
Send the link through messenger? Messenger breaks the link.
SaaS gallery? Some file managers can't open the zip file.
I've been doing that for two years now. Still don't have a 100% working solution. It drives me mad. Just yesterday I spent 30 minutes sending 3 jpeg files to a customer.
# https://stackoverflow.com/questions/9054354/how-to-force-fil...
# https://stackoverflow.com/questions/37131398/how-to-configur...
FYI - I've also recently run across end users who are likely victims of overzealous IT departments that disable Basic Auth, even on HTTPS connections. Even though they don't do anything to form fields which might contain the exact same data. I don't mind if they break their own domains but the whole Internet?
Are your customers using IE6 or something? Customers like that should be fired.
Looks like your company don't want millions of profit?
These days in the same circumstance as you (and they) had, i'd fedex them a USB stick, or optical disc, depending. Because the first time someone said "the web page you linked is just displaying garbage" i'd turn in my tech credentials, because that's probably my server's fault, not the browser. MIME has been a thing for three decades, at least. it sounds like someone tried to use a static html daemon to share a zip file, and it assumes everything is ascii. like it's 19xx and zmodem hasn't been invented yet.
SSL proxies -- corporate middleware -- have a habit of breaking this way, by stripping the content-disposition field or similar.
You can "Get a link" for a transfer you have uploaded and it will be very short and near-unbreakable.
That said, I've had updates (across major versions) break things on multiple occasions, one out of two servers running the exact same version has random crashes and in addition to that the file locking by default (if enabled, but not using Redis: https://docs.nextcloud.com/server/latest/admin_manual/config...) has broken and prevents me from deleting a file that just sits there and takes up a few GB of space. Oh and their Android app fails to upload files if I use the share option, instead of the file picker from within the app.
On the other hand, sure beats storing data on third party clouds and is free, so I'll still keep using it.
And this is how some company can accidentally see way more than it had should.
Never do this for anything remotely important, just add a separate 'Share' folder and allow sharing to external users only from it.
Don't forget, if the user can't see something on the server that doesn't mean there is nothing else there. Eg: ABE enabled SMB share.
[1] https://www.sendutil.com/ [2] https://github.com/timvisee/send
It's WebRTC based so peer-to-peer, E2E encrypted, with servers only used for serving the client, and for NAT punching.
It usually works...
But I agree it’s a mess.
Are you simply unaware these solutions exist?
SnapDrop
- Site: https://snapdrop.net/
- Source: https://github.com/RobinLinus/snapdrop
ShareDrop
- Site: https://www.sharedrop.io/
- Source: https://github.com/szimek/sharedrop
FilePizza
- Site: https://file.pizza/
- Source: https://github.com/kern/filepizza
Original Wormhole
- https://webwormhole.io/
- https://github.com/saljam/webwormhole
- Website: https://send.vis.ee/
- Source: https://github.com/timvisee/send
- List of instances at: https://github.com/timvisee/send-instances
JustBeamIt
- Site: https://justbeamit.com
- Source: https://github.com/justbeamit/beam
https://github.com/coturn/coturn
Now this violates rule #1 (you need an account and you need to pay $6/TB/month for files stored, or $1.5/TB if you store files for only 7 days). For rule #4 you can set the lifecycle arbitrarily, like 1 day, such that the cost of storage is less than the cost of traffic.
https://kdeconnect.kde.org/
KDE works over Bluetooth, I guess, but it was super fast for transferring around 20 to 30 photos at the same (maybe more might also work, didn't try that).
But the most important thing was that I could look at the thumbnails of the photos before marking them for transfer. This process was always very slow with an USB connection, because it was always trying to 'thumbnailize' every photo in the folder (which were 100s or 1000s). Picking the right photos by obscure datetime-name is not fun.
Because they've had to specifically put that limitation in place, no way they don't realise it could be useful.
https://github.com/error-try-again/KDE-Dolphin-TailDrop-Plug...