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

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.

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.

It's pretty typical on HN to see somebody singing the praises of apple while failing to notice the competition provides similar functionality.

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/

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

For me, a pair of netcats has served that use-case quite well.

    python -m http.server 8000

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

    # Linux
    hostname -I

    # Mac
    ifconfig

    # Windows
    ipconfig

    curl -X POST --data-binary @file_to_upload.txt http://192.168.1.X:8000/uploaded_file.txt

    curl http://192.168.1.X:8000/uploads/uploaded_file.txt --output downloaded_file.txt

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.