Best thing about this is that it is available for most of the major platforms with an easy to use GUI. iOS app is excellent.
Some important bugs to beware:
On Windows having the LocalSend app running with the Window visible (after a receive?) prevents the system from sleeping. On Linux, it does the same even if the window isn’t showing. On Linux, having the LocalSend window visible and idle consumes an insane amount of cpu with the desktop window manager constantly refreshing damages. On Windows, the app (with the “startup minimized” option checked) if configured to launch at startup will often show the window anyway (not that you want it running in the background given the sleep issues).
Let me see if I can explain it - These "declarative" UI frameworks work very different from any UI frameworks in the past. They (theoretically) rebuild the data structures backing the current view of the UI and do that 60+ frames per second.
Good thing is that there is very little chance of data-out-of-sync-with-UI kind of bugs. But the bad part is that tons and tons of alloc/dealloc and literally the code is executing all the time.
Now in practice, it is not all that bad. They have a magical garbage collector that makes is all better. Every release it just slightly better, but I can't help think that they are solving a problem they created to begin with. But I might be too old and may be the productivity is worth it.
This is in addition to the fact that none of the widgets are truly native. The "code" is native, but the UI is not. Even react-native apps might be this way, but they at least use Safari/webkit widgets, if not truly native iOS/Android widgets.
Oh okey, I just wanted to be sure we were on the same page. I guess my idea of good performance has been way far off and Flutter is actually performing way worse compared to others.
I did some Googling but could only find comparisons with RN and sometimes with Swift, but not with any of the web frameworks.
I just installed it and it's the most most hassle-free experience I ever had with this type of apps.
My only gripe with it is that I need the receiving device awake and the app on the foreground (at least on android) for it to work. Even with the quick save option activated.
I wish quick share (né nearby share) was available on linux (even if via chrome).
I was talking to my brother about phones the other day and he has to have an iphone for work. He's a federal firefighter in the USA who was hot-shotting all last summer. When they're way out in the middle of nowhere with no cell and no central wifi routers anywhere they use AirDrop to transfer maps and stuff to team members before splitting up. Kinda interesting. Would this tool allow that kind of thing, e.g. for Android to iphone?
Can you elaborate? How does it work without the devices sharing the same Wifi?
I just skimmed the readme. It states a "local network" multiple times. So in this example, the firefighters need a Wifi network to connect the devices. Not because the files are sent over the internet, but because LocalSend doesn't create an ad-hoc network unlike to Airdrop.
So OP: technically yes, but the experience is not quite the same.
Yep, that should be possible and does not require a router. I would think it is significantly less low-friction than native Airdrop for a firefighter on mission though...
It could have an option to create a hidden hotspot and have the other phone also be able to discover the hotspot automatically (app specific SSID name is searched for and if user is not already in wifi, and hidden hotspot doesn't exist, then it will be created for the duration of transfer). Airdrop doesn't seem too different.
a hotspot that provides internet requires a cellular connection, you can still just make a hotspot that has not internet connection and acts as a regular lan
I mean you could build a little server that offers all this one per fire-truck or something, but it's probably overkill when simpler solutions exist :)
Then you could have the fire-trucks mesh network with each other!
Sarcasm alert: I'm sure that is bound to be 100% reliable out in the middle of nowhere, with whatever cheap power converter they used to provide power from the 12V batteries in the truck, and hopefully doesn't drain them :)
> We may update our Privacy Policy from time to time. Thus, you are advised to review this page periodically for any changes. We will notify you of any changes by posting the new Privacy Policy on this page. These changes are effective immediately after they are posted on this page.
There's only a few lines in the entire thing, so I don't know how you can miss that twice they say they don't collect anything in the first place, and then they say:
"Since we do not collect such information, there's no possibility of us using, sharing, or selling this data."
If you want to say that this technically isn't a declaration, I would simply disagree and count it as one.
Frankly, being an open source app, I would be fine if it even said something like "It's open source. If you think it does anything nefarious, go ahead and show it." without even a suggestion of a promise. But they actually do make a declaration of both intent and action.
Any other data that isn't personal data they might have, like their download estimates or something, is theirs none of our business.
What? Collect anything? They say they don't collect personal data. They don't mention what they do with non-personal data.
>Frankly, being an open source app, I would be fine if it even said something like "It's open source. If you think it does anything nefarious, go ahead and show it." without even a suggestion of a promise. But they actually do make a declaration of both intent and action.
That is just horrendous. No. That is not a bar that is acceptable for any app, free, paid, open source or not. Likely illegal too.
> Any other data that isn't personal data they might have, like their download estimates or something, is theirs none of our business.
Or something... such as information about files being sent... Or app telemetry etc.
That was my point.
I don't have reason to distrust them, but calling it the best "privacy policy ever" is a huge stretch given what it lacks.
Less is better. It has nothing because it needs nothing. That's the point.
This is a stupid thing to try to contrive some way to criticize. It's literally as good as it can get.
Also, not doing your homework for you for some free software where you can not only take or leave the software as you please, but have the source too, is maybe illegal? Dude you kill me. Say stuff like that for another 40 minutes and you got a Netflix special.
But what though? Do you have an example of any such thing?
Github makes it effortless to link righ to a specific line of code in a file. Show us a single one of these anythings.
We are talking about the privacy policy. Nothing else.
The policy says that they don't collect, store, or process any personal data. That is great!
What is not great is that the policy does not discuss whether or what type of other non-personal data is collected/stored/processed. That makes it a bad privacy policy. That is what I commented on.
This is like saying that their data & privacy statement doesn't explain the contents of their office refrigerator.
There sure is a disconnect.
What exactly is not great? What's missing?
I see only 2 possible arguments here and neither one seems to actually exist, but you tell me what I'm missing.
One possibility is there is some data that the statement doesn't cover.
Let's see... The statement says they don't posess anything at all. And since the statement is so short, there is no possibility to hide any technicalities in confusing fine print.
So, what data isn't included in "we don't have anything"? What is something the statement says or fails to say?
All I see is farcical things like "aha! but it doesn't say what they are going to do with my email!" 1, yes it does, 2, what email?
The other possibility is the statement is a lie because the code sends them data.
Its amazing to me how AirDrop is such a big plus for Apple ecosystem even in 2024 given technologically it is one of the simplest things possible.
The innovation is purely on the alignment of interests Apple has and its competitors don't because they are all competing with each other and then also Apple.
Google calls this feature "quick share." Of course the problem is that it's all proprietary and Apple has no interest in supporting transfers with non Apple devices.
It's pretty typical on HN to see somebody singing the praises of apple while failing to notice the competition provides similar functionality.
>technologically it is one of the simplest things possible
then how come there are zero FOSS "AirDrop replacements" that seamlessly create an ad-hoc wireless network between two devices to allow for truly p2p high speed transfers?
My guess is that it's difficult to interface with the system's Bluetooth and WiFi sufficiently without a native app on any modern platform (iOS, Android, Mac, Windows, Linux) enough to create and advertise that kind of ad hoc network, without a native app on the device (perhaps even with system permissions).
Since Apple won't implement any third party one, and theirs is natively integrated with their platform, half the ecosystem won't implement or adopt any FOSS alternative.
Since such an alternative won't be pre loaded on handsets (and the Android ecosystem is complex without one single vendor producing firmware everyone ships), the rival would need to be installed manually by users before use.
Not impossible - WhatsApp and other apps have (in some markets) gained near-ubiquity without being built-in, but I think the native app barrier here will always be a hurdle. And Apple presumably knows and strategizes that an alternative won't gain adoption if their half of the ecosystem won't adopt it, therefore holding back the wider market and keeping airdrop functionality as a USP.
There is KDEConnect, which has apps for all major platforms (iOS, android, macOS, Windows and of course Linux) and some more. I even used between Apple devices when AirDrop did not work for some reason.
Proprietary lock-in methods might put you on the cover of CEO Magazine (if that exists), but it's not innovation.
Here's how Apple describes its EU-mandated USB-C port on the iPhone 15, after rejecting criticisms about proprietary cables for years:
"The new USB-C connector lets you charge your Mac or iPad with the same cable you use to charge iPhone 15. You can even use iPhone 15 to charge Apple Watch or AirPods.5 Bye-bye, cable clutter."
The reason this keeps happening is because Apple (and Google) keep widening the feature gap between computers and phones, because the latter gives consumers far less choice when it comes to using third-party applications and peripherals.
It’s 2024. There is still no good generally available way to send files between systems on the same LAN, let alone over the Internet.
These kinds of blind spots exist because not only is there no money in solving them (and open solutions are too hard to use as usual) but in this case there is money in not solving them. A great simple ubiquitous solution would reduce demand for large complicated cloud storage systems that allow cloud data mining of all your files and/or require subscriptions.
All the replies to this show me just how little your average HN user understands the difference between "nerds can do it" and "anyone can do it and it's a standard part of the ecosystem."
Obviously I can move files around. I can also program in 10 languages. I am not normal.
But even for me, it's not convenient. I don't "need" a friendly ubiquitous way to do it, but if I had one it'd be really nice and would save me time.
OS vendors aren't interested in "ubiquitous" because they want to capture people in their walled garden.
Regardless of the quality of any tool, most people will not necessarily use the most friendly way. They will use the tool they already know and have. Reason most people have been using Microsoft Word over the year with very crappy results to share screenshot to people for example. There were plenty of available screenshot tools that would save wherever you want in the format you want, but you had to install them, they were not installed on their windows XP computer out of the box. So you would see people preferring copy/pasting to Word, not even paint or that other image tool I don't remember the name that was available ou of the box on windows.
So nowadays, there is only one thing that is ubiquitous and available in most people devices that allows them to reach other: messaging tools. In the past it was email, nowadays it is Whatsapp. You can make the nicest, fast and friendly tool to share files to others, people will still use Whatsapp to send files to others and even themselves.
there is enough good software out there. If it's only file sharing, then I'd prefer 'LocalSend' . For anything more complex, like send clipboard, push notifications or remote control is 'KDE Connect' my first option, since it's also available for almost any platform.
I've personally had great success with KDE Connect on the LAN for all that (and also as a handy touchpad / keyboard input device for PC). It's one of those "Just Works" tools I always reach for. Also have found SyncThing to be really excellent for keeping folders auto-sync'd between devices. (One personal use-case example for that is keeping my "Pictures" folder in sync between my phone camera and a local folder on one or more of my PCs.)
Rsync has been around along time and works great. I use it almost daily. SFTP has also been a solid option for quite a while. If you want a more permanent network share there's NFS.
A useful utility for sharing (upload and download) files over a local LAN that a friend wrote is https://github.com/akovacs/uploadserver - it's basically a nicer version of:
python -m http.server 8000
You first start one server on a desktop/laptop which has the software, and then any client (Android, iOS, PlayStation, Kindle, etc) with a web browser (no need to install any client software) can upload or download files from it.
You can download prebuilt binaries for x86-64 Linux, Windows 7 or higher, or Mac OS 10.7 Lion or higher (sorry, no prebuilt binaries for Apple Silicon, but they could be added if there is sufficient demand) from https://github.com/akovacs/uploadserver/releases/ or compile from source using a nightly rust toolchain if you prefer.
Start the file server on a desktop machine:
chmod +x upload_server
./upload_server
Determine your machine's IP address using:
# Linux
hostname -I
# Mac
ifconfig
# Windows
ipconfig
Navigate to the server's ip address port 8000 (indicated by the hostname -I command you ran earlier) in the web browser of your choice on any device (no need to download or install any client applications) and upload files using the web UI or directly via curl:
curl -X POST --data-binary @file_to_upload.txt http://192.168.1.X:8000/uploaded_file.txt
Then download the file to another machine or mobile device either from the web GUI or via a commandline tool:
If you don't have a local network, you can setup an adhoc hotspot on any Android 9+ (Settings > Network & internet > Hotspot & tethering https://support.google.com/android/answer/9059108) or iPhone (Settings > Personal Hotspot), then connect to it using any WiFi-enabled device.
Compared to cloud services or `python -m http.server 8000`, this is extremely fast since the server is written in rust, it is fairly simple (compiled and stripped binary is typically less than 3MB), it sends everything over local LAN, it seems to handle large files (over 4GB) fairly well, and you only need to install the software on one machine.
Because people are lazy, and phone makers haven't all agreed on a single sharing app that's preinstalled on every device. Apple own their own ecosystem but are famously "FUCK YOU" to every other platform, but inside their walled garden, AirDrop.
I had the thought once that it would be a useful - if not easy - to submit patches to as many of these projects as possible to allow interoperation (probably by implementing the same protocol(s) in as many as possible). It's the kind of thing where you really want enough common protocol use that most apps can communicate to get network effects.
(But of course, I hardly have the time or perhaps even ability to really go far with that thought. Oh well.)
I use LANDrop, another open source project, with satisfaction. The thing about LocalSend is its low transfer speed. Somehow it’s even slower than LANDrop and much lower than SMB or Croc.
I have also a very weird problem with detection: my iPad can’t send to my Windows PC, but my PC can! Restart server, turn off firewall … all no help. My LAN is a bit complex with VLAN so I didn’t report the issue because it might just be me.
However, LANDrop doesn’t seem to have the same problem. That’s weird square.
I've been using LANDrop between 2 iOS devices, an Android device, 2 Windows devices and an Ubuntu device since I first saw it posted on HN and have never had an issue with it personally.
From my experience where I wanted to send some files from my iPhone to an android based screen in my car, local send and landrop where the best, the rest needed internet or didn’t work properly, like sharedrop, snapdrop, pairdrop, and arc.
I miss Bluetooth for discovery. And Bluetooth for transmission of small files.
* Eliminates the need to be in one network of any kind.
* Allows nearby detection.
* Nowadays good for laptop <-> smartphone
* Possiblilty to create AP with WiFi for big transfers
Bluetooth discovery is the strength of AirDrop. I’m not sure but I think Apple creates a temporary WiFi and the other party is connecting to it briefly for big transfers?
The application Teleport [1] uses Zeroconf for discovery. It misses cross-platform support. Probably it is better use Multicast directly, setup of Avahi is complicated (conflicts) and requires a Daemon.
PS: People often forget that Bluetooth has already the built-in capability to transfer files (e.g. vCard). I only remember GNOME to present it and then also not in Nautilus. Same as WebDAV which works much better than SMB for me. Again, most people just don’t know that there is WebDAV built-in.
The screenshot on the landing page is a slap in the face of Apple, for good reasons, I think.
Yesterday, a friend tried to airdrop a picture to me from his iPhone 11 Pro to my iPhone 15 Pro. Touching the top of the phones did the funny jiggle, but didn't send the file. He then clicked on my picture in AirDrop, which showed him "waiting on confirmation" but I never got a pop-up. After a few retries and reboot, we gave up. He sent me the picture over WhatsApp, which, ironically, "just works."
Apple needs to get these bugs fixed. I lament the fact that they remain more focused on hardware then software.
I frequently use `python -m http.server` on my LAN.
And if I can't be bothered to setup Python on the source host, or there are network complications, running uploadserver[1] on the destination host works great.
I'm wary of all these fancy tools with "magic" in their name, that rely on external relay servers. Even if they don't, I'm quite fond of the simplicity of plain old HTTP. I don't need anything more sophisticated, and in most cases, not even encryption.
netcat/socat would be another solution, but they're not as ubiquitous as Python and HTTP. And I can never remember the command incantations ':D
You first start one server on a desktop/laptop which has the software, and then any client (Android, iOS, PlayStation, Kindle, etc) with a web browser (no need to install any client software) can upload or download files from the web GUI.
You can download prebuilt binaries for x86-64 Linux, Windows, or Mac OS (sorry, no prebuilt binaries for Apple Silicon, but they could be added if there is sufficient demand) from https://github.com/akovacs/uploadserver/releases/ or compile from source using a nightly rust toolchain if you prefer.
Compared to cloud services or `python -m http.server 8000`, this is extremely fast since the server is written in rust, it is fairly simple (compiled and stripped binary is typically less than 3MB), it sends everything over local LAN, it seems to handle large files (over 4GB) fairly well, and you only need to install the software on one machine.
A project idea I've had for a while is to make a library and corresponding apps that implement all of these different sending protocols in one. It seems like every few months, a new p2p file sending app/website is launched and they all basically do the same thing, but very few are inter-compatible. The reason Apple's AirDrop is so good isn't a technical reason, it's because there's just one AirDrop and it's installed on all Apple devices. We need to make one open stuff-sending standard and stop reinventing the wheel. But until then, having one multi-protocol library would be almost as good.
I wrote a similar, but web-based, service focusing on peer to peer file sharing. Since it's a web app, there are file size restrictions imposed by browsers but give it a shot! A signalling server is used for connecting the clients but you don't need it once you're connected to your peer, file data is only ever sent over a P2P connection. By choice, there is no fallback TURN server so some network configurations that aren't able to establish P2P connectivity can't share files. The price of privacy!
I tried to set up Dart runtime and run cli on a Linux server. Then I realized that it just prints a message and quits. Maybe it's better to directly tell user cli isn't implemented yet.
Great stuff! I wonder if it's possible to make it available as a web app? It would be even cooler if no app install is required, just send the link to a receiver via text message.
And when I have larger content that needs to be shared, Signal's "Note to Self" works across platforms also. (It's the only reason I have Signal installed since I don't use it for communications)
Does anyone knows if it is possible to send folders (includings subfolders) or is just files?
Have been looking for a simple way to share files between pc and android wireless but not via internet, but seems it always is just file/s you could transfer, not folders with everything in them.
If LocalSend is the same and can only transfer selected file/s, have anyone any tips on a alternative app that do the same but also with folders?
Haha that’s currently a way to explain to people who are used to hosting/sync based cloud solutions that anything that is (a) local p2p and (b) doesn’t need to upload-before-download is much faster. It’s also faster than WebRTC based solutions which there are dozens, WebRTC kind of sucks for large stuff.
That said, the next version will have multi connection tcp striping, which is a lot faster than any single tcp solution in many cases, especially over long distances, similar to some ftp/usenet clients. (Spoiler there will be online p2p transfers. See https://github.com/betamos/rdv if curious)
If you can install software on the computer and have an Android 11 or newer phone, one way is to use the adb tool from android sdk tools to create a connection over the local wifi network which you can adb push folders over.
Probably not what you are looking for, but Syncthing, Syncthing Fork on Android, if you have LAN. You can switch on only local announce (switch global off in adv. settings).
Not saying this is totally worthless but the magic of Airdrop is that people do NOT have to be on the same network and that it does not need any network infrastructure in the first place.
I continue to use TrebleShot[0] although it's repo is archived since it also enables browsing files using a Web browser. So you don't need to install it on the receiver side.
I'm using snapdrop.net for that. It requires a server, but clients only need to open a webpage, so it's easier after initial setup.
I run mine on Synology server.
That’s what I’d really like when sending stuff between my devices because my most common use case is I see or think of something work-related when I’m off and don’t want to dig out the company laptop to make note of it, or the other way around see a personal interest or a nerd snipe while at work and want to stash it for off-the-clock.
I usually sling mails between devices, less commonly stash something in iCloud (or similar), but those are pretty noisy and high overhead workflows.
that's because Google actively won't implement it... not sure why but there was issues with "thousands" of comments requesting it (because it is part of WiFi standard). Not sure about Apple.
Am I sure that I've used Taildrop on my Android phone, Linux, Windows, Mac and Synology? Yes I am sure.
Maybe not great wording or arrangement of statements on that page since it seems to have stopped you in your tracks reading at that point, but you can scroll down and see discussion of using it on other platforms. What you're hyper-focused on is a subsection under the heading specifically dealing with Synology.
Geez, that was rude. I don't think assuming that the literally first requirement mentioned conditions the rest is "hyper focusing." It seems prudent to assume the rest are conditioned on it. It's not outlandish to assume you have to be on that style of network to use it, especially since the pitch is to enterprises for secure file transfer.
Taildrop is "a filetransfer for your personal devices", it only works if you have a Tailscale network transferring to QNAP/Synology is a nice feature. We all see thing from different perspectives it really helps to try understand why that might be.
Some important bugs to beware:
On Windows having the LocalSend app running with the Window visible (after a receive?) prevents the system from sleeping. On Linux, it does the same even if the window isn’t showing. On Linux, having the LocalSend window visible and idle consumes an insane amount of cpu with the desktop window manager constantly refreshing damages. On Windows, the app (with the “startup minimized” option checked) if configured to launch at startup will often show the window anyway (not that you want it running in the background given the sleep issues).