Localsend: Open-Source Airdrop Alternative
github.com
github.com
'LocalSend uses a secure communication protocol that allows devices to communicate with each other using a REST API. All data is sent securely over HTTPS, and the TLS/SSL certificate is generated on the fly on each device, ensuring maximum security.'
How do they achieve maximum security while generating X.509 certs on device?
Let's look; 'https://github.com/localsend/protocol#2-fingerprint'
'When encryption is on (HTTPS), then the fingerprint is the SHA-256 hash of the certificate'
Confusingly there is a HTTP non encrypted mode, and the docs claim the fingerprint only used to avoid discovery collisions.
Out-of-band [visual comparison / QR code scanning step] sharing of fingerprints COULD be acceptable to prevent 'man in the middle' attacks, however the documentation doesn't seem to indicate that this detail is surfaced or shared with the user. The discovery protocols look 'hella sus', but most local media sharing and discovery is.
Still hoping for some alternatives that can do ad-hoc communication, without any network infrastructure.
Wifi got a bunch of ambient discovery capabilities a bit back that seems exactly targeted to this stuff. Neighbor Awareness Networking, or WiFi Aware for the trademarked industry packaging there-of. It was built into Android 8. There's also even older wifi-p2p/wifi direct (again, spec vs industry branding for the same thing).
I haven't looked in a bit, but I'd love to see a Linux based toolkit around this, that interops with Android, but isn't so handcuffed down by Google.
Google - like Apple - has some ultra proprietary tied-to-your account peer-to-peer stuff. There's Nearby Connections for app devs, such as for AR games. There's Nearby Share for file sharing, which I hear might maybe be getting a Windows implementation but again seems locked down. I want so bad to see some drive forward on the transport layer, & we have so much to go with. Its a solid bet hostapd technically supports all these capabilities (it just does everything under the sun in wifi best I can tell), but we haven't harnessed this source.
That’s the real benefit of Airdrop. It’s so nice when you’re traveling to be able to share photos with someone you just met without worrying about WiFi hotspots, mobile data plans or any of that. You can be out in the middle of the ocean and it just works.
AirDrop is fast (actual transfer happens over WiFi) and easy - makes it so you don’t need to know anything about Bluetooth to use it. It’s a challenge to find an alternative app with the same level of functionality.
1. local IP network, if available
2. ad hoc WiFi, if possible
3. the Bluetooth connection
4. fallback via Apple's servers (newest iOS only)
It's primary advantage is its ability to negotiate over a number of different interfaces and protocols, as needed.
The requirement for network infrastructure can be worked around by creating an ad-hoc wifi network.
Unfortunately for 95% of people that you want want to share files with, that’s a total dealbreaker.
The problem with these is that interop is a nightmare. And interop is exactly what you want to get 99.9% working, otherwise the tech is moot.
Apple, and to an extent Google, can do it thanks to their control of the vertical stack. Open-source... has a harder time about it.
Their whole market strategy is the exact opposite. They only implement standards when forced by regulations or overwhelming market forces.
EDIT: I have just seen they have recently introduced matter support for iot devices. This is a big step in the right direction!
A useful filesharing utility that a friend wrote is https://github.com/akovacs/uploadserver - it's basically a nicer version of:
python -m http.server 8000
Determine your machine's IP address using:
# Linux
hostname -I
# Mac
ifconfig
# Windows
ipconfig
chmod +x upload_server
./upload_server
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.txtHere's the protocol docs — both devices just tell each other that they're "unable" to do "paired key encryption" and the connection continues: https://github.com/grishka/NearDrop/blob/master/PROTOCOL.md
I have been very interested in this. Sadly, finding hardware that supports it (both HW and SW) seems quite hard at the moment. This stackoverflow answer mentions a few, but I have no idea about software support: https://stackoverflow.com/a/54214808/3795597
I tried poking around the Linux drivers and userspace tools (which required reading some source code, the documentation is pretty bad), I summed up some of my finding there: https://superuser.com/a/1786039
So far, I only encountered two phone series that supported NAN: POCO and Google Pixel. So much for interoperability. I still wonder if it's possible to build a compatible implementation leveraging Monitor mode. This is how Owl (open source "Airdrop"/ADWL implementation) does it: https://github.com/seemoo-lab/owl
But Apple only.. makes it much less useful, even for “Apple people”.
Many Windows and Android devices have been able to share a Wi-Fi network with other devices over another SSID, for example.
The only thing that's complicated is if a device needs to be a 802.11 station on one frequency/channel, and a host or P2P device on another, but that's almost always avoidable.
Everything else can be done purely in firmware or software.
Do you have any sources for that? As far as I know, it's just time-sharing the same baseband and hardware used for regular infrastructure-mode Wi-Fi.
No, I should have picked my words more carefully. All I know is that they can be part of two networks at the same time.
I use apple's IP audio streaming protocol (forget what it's called, air-something) to play music over a couple of edifier-brand speakers from a Linux desktop which is running pipewire's FOSS implementation of the protocol. I don't even buy apple products but i ended up using it because there's no way to just netcat samples onto these things.
I wish everything were as simple to use.
Documents is the other app I use for sending files to and from iOS (primarily iPad, from Linux laptops). But I’ve run into a lot more bugs with that, and the transfer setup process requires generating and entering codes. It’s a pretty good UX, but it always reminds you how effortless airdrop is.
I love the idea of a cross platform, open source, airdrop. It’s a lofty, but worthwhile goal.
And operating systems could allow user to select their preferred server, although I wouldn't expect Apple to allow something advanced and anti-vendor-locking like that.
[0] https://blog.pushbullet.com/2014/08/20/introducing-universal... [1] https://kdeconnect.kde.org/download.html
Interestingly, it seems to present shared KBs and mice as physically connected devices. Any time I use Universal Control on a Mac I haven’t before the little keyboard identification assistant that opens when you directly plug in a keyboard pops up.
I sometimes need to work on mobile development, so on advice from a sibling comment I installed KDE Connect, and it's actually pretty great and does copy/paste and remote mouse/keyboard pretty well, but you do have to a) enter the app, b) select the device, c) then finally choose the thing you want to do. They've made it about as frictionless as possible, but it won't be the same as first-class OS-level support. e.g., I can just copy some text on my Mac, and paste it a second later on my iPhone, without any manual orchestration
“We’ll just do these steps and poof it will be on your machine! One second… Hang on… let’s try again…”
Airdrop Discovery is slow. Notification of an incoming file is slow. File transfer startup is slow. File transfer completion is slow.
You have to wait at every step and you cannot stop watching it, lest the transfer fail.
The UI for iOS isn't very good either. It floats on top of everything. It's easy to dismiss and impossible to bring back without starting over.
It's a great idea with bad UX, but still better than nothing at all.
The lack of notification when you are receiving is annoying though.
I'm thinking things along the lines of privacy, security, speed, etc
First impression has been quite disappointing... I installed the PWA to my phone's home screen. Then opened up and paired with my PC as trusted device. Tried to send a PDF file from PC to phone, a dialog shows up with
File Received. PC has sent: file.pdf. Close/Download.
Upon clicking Download, Firefox (which is configured in Android as the default web browser) opens up, on the Homepage tab. Nothing else happens, and the file isn't downloaded. So I'm left pretty much confused about what should have happened vs. what did actually happen.
(EDIT: Turns out installing the PWA from Firefox doesn't work as well as doing the same from Chrome. The latter does actually integrate it as a real Android app, and it then works as expected. The Firefox integration of PWAs with Android is a bit lacking, it seems.)
Good thing about Warpinator (and something I use a lot) is that you can enable accepting files without confirmation, and then you can drag & drop a whole folder to have it appear on the other device as-is. Something extremely useful but that I doubt web apps can achieve.
I do prefer the WebApp approach so I don't have to install something on each machine before sharing files, but the bug ticket in Pairdrop does not make me hopeful for a good solution (see: https://github.com/schlagmichdoch/PairDrop/issues/44)
Are you able to achieve similar performance in Pairdrop that you did with Localsend?
I must say LocalSend seems pretty great (even though they’re a “direct competitor” to my app https://payload.app/ )
Send an email and I can put you in the announcement list (1-2 posts per year tops).
Disclaimer: I'm the author of drop.lol.
Thanks for reminding me.
Update: Fixed. (Expected this to require a rewrite but... it was just a matter of passing one option to react-router.)
I've just tested on Chromium 118.0.5993.70, Firefox 118.0.2 and Safari (iOS 17.0.3) and the issue seems to be gone.
In what ways?
To quickly copy file from one machine to another.
# on target machine
$ nc -l PORT > file
# on source machine
$ cat file | nc HOST PORT
# on target machine
$ nc -l PORT | tar xf -
# on source machine
$ tar cf - FOLDER | nc HOST PORTFrom the author: https://github.com/schlagmichdoch/pairdrop#differences-to-sn...
1: https://github.com/marcosdiez/shareviahttp
2: https://github.com/uintdev/qrserv
3: also in the IzzyOnDroid F-droid repo
Technically they will still need an app to download the file (even if just a web browser) but there’s a gulf of difference between using an app you already have or installing a new one, especially if you need to do all the due diligence of “do I trust this?”
The IP and port is just also shown, which is very useful when the target device doesn't have an easy QR code scanner - say, a desktop.
Not that it matters at all. As others have said, the app will gladly show you a QR code for it, which regular smartphone users are trained to use.
As for the credit/debit card number, it isn't comparable as it is widely used and understood. And yes, QR code is a far better solution, and it is employed by most apps.
Heck, the number is even organized similar: the CC is 4 groups of 8 + a group of 3 (ignoring date and name), the IP and port is 4 groups of average 2 digits + a group of 5. And unlike the CC info, every IP a non-techie ever deals with - and they have most certainly seen and typed one at least few times at this point, such as when they got internet service - starts with the same 6 digits.
Not to mention electronic bills and bank accounts/SWIFT/IBAN being even longer and copied without fail.
> And remember, most people don't have enough patience to retype the address once it didn't work.
What? If people have the patience to retype CC info when wrong, they have the patience to try typing an IP again.
Heck, the only use for this feature at all is if you're two people where one has the app and the other does not, so it's two people that need to collectively fail and give up!
You can say that it's annoying to copy an IP, but the task is objectively simpler and less time consuming than other regular day-to-day activities a smartphone owner would go through. The suggestion that two people should collectively fail the task is, quite frankly, ridiculous.
> A QR code is a far better solution
Then just use that instead of ranting about how IPs are unacceptable. The button for the QR code is right beside the address in the app. Or if that's too difficult, install the app on both devices so it's automatic.
You mentioned electronic bills (idk what that is), bank account/SWIFT/IBAN. You maybe suprised, but these people don't type these numbers at all. They don't ever need to. The most they can type is a phone number.
People have more patience to type CC number because it's more important to them than receiving a file, which can be easily shared through WhatsApp etc. For larger files, they will just copy using a data cable, or pendrive.
> And unlike the CC info, every IP a non-techie ever deals with - and they have most certainly seen and typed one at least few times at this point, such as when they got internet service - starts with the same 6 digits.
Yeah, keep living in your bubble. One rarely needs to type an IP address to use a modern fiber optics internet connection. It's generally pre-cofigured.
> A QR code is a far better solution
> Then just use that instead of ranting about how IPs are unacceptable.
Yes, and I am always going to choose the QR code over typing IP address manually any time of the day.
> You mentioned electronic bills (idk what that is), bank account/SWIFT/IBAN. You maybe suprised, but these people don't type these numbers at all.
The average individual must pay bills, and that involves copying payment details. Here, that means copying numeric payment details - either a special bill number or bank details.
Likewise if you work in an office you may be confronted with invoices paid by bank transfer.
There can be local variations in means of payment of course, but unless you live in a cash-only world it would not be avoidable.
> People have more patience to type CC number because it's more important to them than receiving a file
There is nothing that would support this claim. It is quite conceivable that a file would be important to someone but a random online purchase not.
> Yeah, keep living in your bubble. One rarely needs to type an IP address to use a modern fiber optics internet connection. It's generally pre-cofigured.
Sure as hell never was for me across 2 countries and 4 providers. Always required activation, and ISP instructions often had you go to the router portal.
Granted I didn't use their router after activation, but 192.168.1.1 (or 0.1) is something users are guided to.
I cannot claim that every ISP will require this, but in my experience it is "many", which in turn exposes at least one individual in a household.
> Yes, and I am always going to choose the QR code
Go ahead - no need to go on a pointless vendetta when your preferred option is right there.
Payments happen mostly through apps here. So people don't have to type numbers.
Even if they have to use bank account details or card details to pay, only one person in the household generally does that. If your target user is that one person, then you will be fine.
> Likewise if you work in an office you may be confronted with invoices paid by bank transfer.
If you work in an office, you will be specifically trained for that. Your file transfer app can't as people don't have the patience to read through your guide.
> There is nothing that would support this claim. It is quite conceivable that a file would be important to someone but a random online purchase not.
As I said, instead of going through the hassle of typing IP addresses and making sure both devices are on the same network, people will just send the file over messaging apps or email. They will use your file transfer app if and only if it is as easy or easier than say WhatsApp.
> Sure as hell never was for me across 2 countries and 4 providers. Always required activation, and ISP instructions often had you go to the router portal.
Idk, but I didn't have to. Or even if it is required, a technician will most probably do it for them. Moreover if you keep your router in default configuration, you don't need to configure most things. Only power users get into that stuff.
> Go ahead - no need to go on a pointless vendetta when your preferred option is right there.
I am just trying to put my opinion forward. I generally use nearby share on Android.
In EU, Giro//SEPA is used for most formal electronically paid bills. Electricity, internet, rent, fines (parking, speeding, ...), tax adjustments, whatever. Where I live, it would be impossible for an employed adult to not be confronted with such non-app payments occasionally.
But even then, people need to enter CC details at regular intervals, they may deal with multiple, and even if they could get familiar with them they change as CCs are renewed or replaced.
> If you work in an office, you will be specifically trained for that.
That training makes you able to copy long sequences of unique and mostly meaningless numbers without error, exactly the skill required here.
> As I said, instead of going through the hassle of typing IP addresses and making sure both devices are on the same network, people will just send the file over messaging apps or email.
If either user installed the app they likely have a reason to not just send it by email (larger than email limit, internet speed), whatsapp (not a user, not installed, no trust), or airdrop/nearby share (support) in the first place.
Being on the same network is of course a restriction, but that's the whole premise of the app. I'd also consider any smartphone user able to connect to a WiFi network, and "be on the same one" while more technical seems like a manageable task. The assumption is not that the average user will think of making a portable hotspot, but rather that they find WiFi to connect to (e.g., home or office).
It would be neater to use WiFi P2P, but that's also trickier.
It finds devices on the same network automatically but also works across networks when using the plus button on the top right.
I've tried all the options in this thread but only discovered pairdrop 20 minutes ago (thanks to this thread) and it's by far the best option.
Problem is that you both need to be on the same network for this to work.
Sure, I could quickly start a hotspot and share that with a qr-code and then share my ip+port with another qr code.
Whole setup is like 6 clicks, but... The receiving side needs to join a wifi (and implicitly disconnect from something they might be using, and then have to switch back afterwards) and scan ² qr codes.
All in all, too cumbersome.
Being in the same network, of course, lowers the difficulty bar because now the peers don't need to perform an initial step of creating their own network link between phones.
And many apps are running their own direct wifi-wifi, tons of ways to do it. No real reason for why it couldn't be native to all devices that exist.
The problem is that airdrop only works with apple devices so that is utterly useless. Nearby-share is equivalently useless.
Hotspot works, but only in some cases. About as convenient as unpacking a laptop and sharing thumb-drives. Which is a pretty embarrassing state of affairs in 2023.
I took a quick self evaluation and concluded that I'm not possessed by demonic powers, I don't have excess electromagnetic radiation and other supernatural explanation. I remembered the "OpenOffice will never print on Tuesdays" and "My car doesn’t like vanilla ice-cream" stories so it got me curious what changes. The only thing that I added to the equation was my Android phone connected to Wifi. I put it to airplane mode and voilà, AirDrop started working.
Last week a family member wanted to transfer some files from Windows to iPad (without passing through iCloud), and it was a nightmare. Windows 11 is already so weird with their online accounts and stuff, that just getting a network share to work was painful.
And "thanks" to Apple being Apple, I also could not use USB-C to transfer from an external drive to the iPad because I didn't have an adapter.
So I'll definitely try this.
https://github.com/localsend/protocol#2-fingerprint-%E6%8C%8...
> The fingerprint is used to avoid self-discovery and to remember devices.
https://github.com/localsend/protocol#31-multicast-udp-defau...
> The fingerprint is only used to avoid self-discovering.
0: https://trebleshot.monora.org/ 1: https://github.com/trebleshot
> This repository has been archived by the owner on Sep 4, 2021. It is now read-only.
Don't think this project is active anymore, and I cannot find any download links for desktop.
(But they can still be spoofed in ways client can't detect, especially if humans verbally verify by alias).
The practical solution to “share files in physical proximity” ends up being just use Apple everything.
No website or arcane CLI to use and the app is self-contained and package well enough to give to anyone that is not a techie.
Bonus for not using Electron for this basic utility.
Check it out here: https://github.com/schlagmichdoch/PairDrop
Or try it out here: https://pairdrop.net/
- FlyingCarpet: direct transfer over local adhoc WIFI: https://github.com/spieglt/FlyingCarpet
- LANDrop: Drop any files to any devices on your LAN: https://github.com/LANDrop/LANDrop
- Snapdrop: In-browser file transfer similar to Airdrop: https://snapdrop.net/
- Magic Wormhole: simple file transfer from computer-to-computer over the net: https://github.com/magic-wormhole/magic-wormhole
- Croc: similar to magic wormhole: https://github.com/schollz/croc
- Wormhole: user-friendly in-browser based e2e encrypted file transfer: https://wormhole.app/
https://pairdrop.net/ is a fork of SnapDrop with a more responsive maintainer (apparently: https://github.com/schlagmichdoch/PairDrop/discussions/115)
They’re simply not incentivised to have cross platform sharing of files. If anything, they’d rather keep files within their own branded cloud storage system and have users share links instead. It’s all about adoption and subscription revenue.
If you send 100+ photos it won't work consistently. Or if you try to send one big file it'll typically interrupt somewhere in the middle. It doesn't seem to have any internal mechanism to recover and restart file transfer
I use Destiny, which is magic-wormhole for iOS:
https://apps.apple.com/us/app/destiny-secure-file-transfer/i...
https://github.com/LeastAuthority/destiny
Unfortunately it uses different mailbox URLs from magic wormhole, so it isn’t compatible with those clients.
Like, if any time someone mained one of these systems, you could assume you had it. Even do discovery for everything at once on the receive side, and if both of you have the omni-sender thing just pick what protocol to send it over.
For example, to use the "wormhole" Python CLI with Destiny, you can do this:
wormhole --relay-url wss://mailbox.mw.leastauthority.com/v1 --transit-helper tcp:relay.mw.leastauthority.com:4001 send README.rst
Then, the code it prints out can be consumed by a Destiny (or https://winden.app ) client.
"Destiny" is an Android and iOS client https://github.com/LeastAuthority/destiny/
(These two use servers run by Least Authority by default so to talk to other clients you have to configure Destiny to use the defaults, or the other side to use the non-default servers).
Pardon the ignorance but why would someone use Magic Wormhole to transfer files/messages between computers on the same LAN. Would there be a rendezvous server listening on a local address. What if the two devices are owned by the same person.
If they use the Magic Wormhole default settings the files/messages will travel over the internet, using a third party rendezvous server.
I am very, very sure this is incorrect. The rendezvous indeed happens over the internet with their default handshake server, but the transfer itself should run in LAN.
Perhaps Magic Wormhole has an option to forward traffic (if so, IMHO that's not peer-to-peer) but I only meant the process of setting peer-to-peer connections requires packets to travel over the internet and, by default, to a third party server.
All the contents of these messages are end-to-end encrypted so you reveal which two IP addresses are communicating, but not the contents of those communications. (If you don't want to reveal that, use the Tor options).
The "bulk transfer" connection should be over the LAN only if both devices are on the same network. In any case, all of these messages are also end-to-end encrypted as well.
Click on file you want to download. Does not use mobile internet or outside wifi.
This one is using Gtk and Avahi (Zeroconf). The idea of using parts of the public Apple-Stuff makes sense? What it misses is Bluetooth because only Bluetooth make it working universally (no need to be on same network initially).
Rymdport [2] is a decent cross-platform app using it.
[1] https://github.com/psanford/wormhole-william [2] https://github.com/Jacalz/rymdport
It's also for that though. I routinely share things with my girlfriend via Airdrop because it's the most convenient solution
And if it is short textual data it is more easily shared with a qrcode.
However is does work on your own computers only and it can’t work on iOS since background tasks are not possible.
Mobius sync uses it on iOS I think!
"No iOS app can run continuously in the background. This means that Möbius Sync can only connect to other devices whilst the app is open, for a short time thereafter, and whenever it is triggered to run briefly in the background."