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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
> 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.
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.
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.
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 :)
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
179 comments
[ 3.0 ms ] story [ 217 ms ] threadNot to say they have no overlap, I use both. LocalSend is nice to quickly send that one picture from my Android to my MacBook
Airdrop even requires bluetooth.
https://issuetracker.google.com/issues/36904180 (won't fix, obsolete, according to these mofos)
https://i.imgur.com/xei98fy.png (who the fuck knows how many more comments it would have got if they didn't block commenting)
It was implemented once on Cyanogenmod thought...
A lot of the posts about this have been de-indexed from Google Search too.
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.
I usually use Firefox Sync to send myself tabs.
Croc: https://github.com/schollz/croc
Magic-Wormhole: https://github.com/magic-wormhole/magic-wormhole
I used to use MW but switched to croc as the single binary was easier to deploy.
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.
For me, a pair of netcats has served that use-case quite well.
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:
Determine your machine's IP address using: 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: 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.
Also what about syncthing[1] (for recurrent/permanent sync) and croc[2] (for one time copies) ?
I have used both for a number of years already. Before croc, magic wormhole was available for even longer.
[1] https://syncthing.net/
[2] https://github.com/schollz/croc
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.
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.
(But of course, I hardly have the time or perhaps even ability to really go far with that thought. Oh well.)
https://wormhole.app/
Via https://tailscale.com/kb/1106/taildrop:
- "Since Taildrop is an alpha feature, you’ll need to opt your network in to the test to use it."
- "Taildrop is only available on Synology with Tailscale v1.18.2".
- "Currently that means you need to manually install Tailscale on your Synology NAS."
Taking Occam's Razor to it:
- Buy Enterprise™ hardware to use alpha software.
- "more secure" has a prefix of "maybe" and a suffix of "(?)" in the comment recommending it
I'm ruling it out altogether.
> - "Taildrop is only available on Synology with Tailscale v1.18.2".
> - "Currently that means you need to manually install Tailscale on your Synology NAS."
Only apply if you're installing it ON Synology hardware, otherwise it is matter of installing the tailscale client and opting your network in.
"Taildrop is only available on Synology with Tailscale v1.18.2 or later."
That sentence is the first sentence under the "Setting up Taildrop on Synology" section of the documentation.
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.
I have used such apps before, but it seems they have gone unmaintained and don't work anymore.
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
[1]: https://pypi.org/project/uploadserver/
https://github.com/localsend/protocol?tab=readme-ov-file#51-...
Or do you mean uploading with an http frontend?
- B: Yes, uploading via a web page would be nice too. I have seen other apps do this.
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.
For additional details, please see: https://news.ycombinator.com/item?id=39665095
Even works over tailscale on Wifi with Client isolation on.
Too bad it seems to not be mantained anymore
# Browser Based
1. FilePizza https://file.pizza/
2. SnapDrop https://snapdrop.net/ https://github.com/RobinLinus/snapdrop. A fork PairDrop https://github.com/schlagmichdoch/pairdrop
3. Instant.io https://instant.io/
4. file ai http://fileai.com/
5. Send Anywhere https://send-anywhere.com/
6. Just Beaam it https://www.justbeamit.com/
7. Yt2fb.in https://yt2fb.in/file-transfer/
8. drop.lol https://drop.lol/ https://github.com/mat-sz/filedrop
# CLI
1. croc https://github.com/schollz/croc
2. p2pcopy https://github.com/psantosl/p2pcopy
3. pcp https://github.com/dennis-tra/pcp
4. wormhole-william https://github.com/psanford/wormhole-william
[1]: https://gist.github.com/SMUsamaShah/fd6e275e44009b72f64d0570...
LANDrop - https://landrop.app/
ShareDrop - https://www.sharedrop.io/
beamit - https://justbeamit.com/
payload - https://payload.app/ (as mentioned)
pairdrop - https://pairdrop.net/
all via https://news.ycombinator.com/item?id=37251411
Also:
pixeldrain - https://pixeldrain.com/
https://github.com/fm-sys/snapdrop-android/issues/356#issuec...
https://webwormhole.io/
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).
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 made NearDrop, which is a macOS implementation of Nearby Share: https://github.com/grishka/NearDrop
And of course, someone tried to reimplement it for other OSes: https://github.com/PlutoHDDev/CrossDrop
so Flutter :)
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.
Considering what you said, it's quite impressive that Flutter is able to perform this well and render thousands of widgets per second.
https://youtu.be/pD38Yyz7N2E?si=7jTaQdX9ln37_fHR&t=3052
Also what if I want to run other apps at the same time? They better not have too many widgets of their own?
Regarding your other question, I don’t know.
That's not what I'm saying. I'm saying rerendering and updating the state of thousands widgets PER second.
I did some Googling but could only find comparisons with RN and sometimes with Swift, but not with any of the web frameworks.
https://codeberg.org/localsend/localsend
While GitHub is not open source, LocalSend is under the MIT License: https://codeberg.org/localsend/localsend/src/branch/main/LIC...
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.
>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.
Information about files being sent could be anything from metadata, checksums, to something like (but not likely) CSAM.
Could also be data about your device(s), anything really.
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.
You mention earlier data about your devices, this seems to me like it would fall into the `personal data` category, and be excluded.
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.
Does it?
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.
This actually seems really awful?
https://github.com/localsend/localsend/issues/29
It's pretty typical on HN to see somebody singing the praises of apple while failing to notice the competition provides similar functionality.
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?
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.
https://kdeconnect.kde.org/
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."
https://www.apple.com/ca/iphone-15/
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.
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.
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 :)
https://developer.android.com/develop/connectivity/wifi/loca...