All of these "alternatives to airdop" don't seem to actually do what airdrop does, which is create an ad-hoc wireless connection. Airdrop isn't just a nice UI for sending files between people, it allows a wi-fi speed transfer between two devices that aren't connected to an existing network of that speed.
Thanks for the link. Looking through the Github, this appears to be close to what I'm looking for on my own project. Namely, being able to share files automatically with nearby devices when they move within range.
I thought Bluetooth might be viable, as beacons and GattServers seem to be designed for this purpose. Android's implementation was painful, yet doable. However, after wading into Microsoft's codebase, I suspect it will be slog.
Question: With an agreed upon network name or configuration, and agreed upon access parameters, how much change do you think it would take for FlyingCarpet to instead by used as a semi-anonymous, dynamic membership mesh network?
Ex: A laptop and a phone get near each other, they recognize their proximity, and that they are both offering the known network, they then check for the presence of known filetypes in a known folder location, and exchange small updates with each other. The same with any number of desktops, laptops, or phones that get near each other. If I was in a mall with 11 other similarly configured phones nearby, and 5 people working on laptops, then my phone would call the 16 other devices, and they would each get a file from my phone, and I would get a file from their phones.
This. Airdrop is actually viable for transferring huge files, like RAW photos or ProRes footage. I've had video engineering professionals ask me if it's viable to implement Airdrop support in something like a camera or a recorder, not because it's pretty or doesn't need cables, but because it would save them time in a media workflow (they are busy people).
I was pleasantly pleased to recently learn Airdrop has no file size limitation! I needed to transfer several 7-9 GB files and thought for sure I'd run into issues but everything moved smooth (and quickly!).
Apple usually does excellent integrations between their devices. But I haven't used AirDrop so I'm not familiar with how it works: in order to create an ad-hoc wireless connection, if the devices were already connected to some wifi access point, are they temporarily disconnected for the duration of the ad-hoc connection?
If not, I'd guess that Apple devices maybe come with 2 WiFi adapters inside?
Neither — frequency hopping is used so that the device can establish AWDL connectivity directly with nearby devices while maintaining a connection to an access point, while still only having a single Wi-Fi adapter.
AirPlay and Miracast both rely on WiFi (in case of Miracast it's WiFi Direct, for AirPlay I'm not sure), so it's not uncommon for WiFi chips to maintain 2 connections at once.
No they don’t disconnect from WiFi and as of the latest iOS you can now leave airdrop radius and it will use the internet to continue transfer. Its magic
"All of these "alternatives to airdop" don't seem to actually do what airdrop does, which is create an ad-hoc wireless connection."
Not all of them.
"Airdrop isn't just a nice UI for sending files between people, it allows a wi-fi speed transfer between two [Apple] devices that aren't connected to an existing network of that speed."
More precisely, WiFi Direct allows it.
There is no reason why one should not be able to use WiFi Direct to transfer files between Apple hardware and non-Apple hardware.
But Apple and Google, via iOS and Android, stop users from using WiFi Direct to do it.
Everyone who buys a computer from these companies should be able to write applications that use WiFi Direct. The chips support it. The buyers own the hardware, not Apple or Google.
I routinely use airdrop to transfer mapping data when fighting bushfires in remote areas. There’s no network of any kind on most of these, but with a geocoded PDF map and Avenza we can still plot going edges, mark hotspots and dangerous trees, etc.
Being able to quickly squirt all of that, including photos, to another crew is a literal lifesaver.
Every Android device I've used has had "Send via Bluetooth" functionality built in. Is the WiFi connection just significantly faster or does it provide other additional benefits?
Apple Watches used to update over Bluetooth and it would take hours, literally. And someone discovered a trick to turn off Bluetooth to force it to update over Wi-Fi, and then the download took just minutes.
most wifi is probably 2 orders of magnitude faster than bluetooth transfer. Syncthing is great if you're looking for multiplatform syncing of files. It takes a little playing around though, the interface is not what I would call beginner friendly, but it's not too bad, and has been very dependable in my experience
You can create a hotspot and start a HTTP server. Scan a QR code to connect to the hotspot, then a QR code for the file URL. It's easy and works with any device with Wifi access.
For the server, on Android I use "Share via HTTP". On desktop running a lightweight HTTP server is easy too.
Edit:
Apparently that sounded complicated, here is how I can share a file from my phone to any other phone in the same Wifi.
- Click Share -> Share with HTTP.
- The app opens and shows a QR code.
- Other person scans the code. Their browser opens the file and they can do whatever they want with it.
If you have no Wifi:
- Open QR code for hotspot
- Other person scans QR code for hotspot, then for file.
If you still think it is too complicated, surely there is an opportunity create a simpler UI! From a technology perspective it does not have to be complicated.
> here is how I can share a file from my phone to any other phone in the same Wifi.
This will not work on many public and corporate networks. A common place where you’d want to share.
> surely there is an opportunity create a simpler UI!
It’ll still suck compared to Airdrop. Apple has gone to a lot of trouble to make that work as well as it does. Trying to setup something relying on temporary hotspots will be sub par UX. (And a nonstarter for Apple devices - user apps can’t touch the WiFi settings).
ISTR around something like the Galaxy Nexus Google doing demos of beaming files between devices via WiFi Direct after having exchanged info with an NFC tap.
But that was just before they decided everything had to go via their cloud.
Curiously if you used a London bus in around 2005 with bluetooth on you would experience a lot of files being sent to you via ad hoc networks.
It doesn't do what airdrop does, although it is a step better than Sharedrop, in that it doesn't require the data be sent over the internet. But it still has a lot of extra hassle that airdrop doesn't have. If you're away from home, you first have to enable Mobile Hotspot to create a wifi network (and pay your carrier for the right, since it's usually locked down in Android), then manually connect your other device to that wifi. Airdrop skips all of that. If Airdrop is open, it's scanning via bluetooth for another device with Airdrop enabled (it doesnt even have to be open). Then they instantly agree on an ad-hoc network and connect, all invisibly to the user. So you don't do anything at all. I wish a Android developer could accomplish this.
How do you figure that? I don't know anything about how this works, but ad-hoc Wi-Fi connections are a thing, and they use good ol' TCP/IP. It just means you don't connect to some pre-existing Wi-Fi network managed by some third party (from the exchanging terminals' perspective).
1. How do you know this?
2. Even if it's the case, why would it be wrong if it's the best choice for the requirements? (incredibly simple, fast, reliable local file sharing). TCP/IP isn't the end-all be-all.
I've tried a lot of similar tools for sending files between devices in local area network and found that https://localsend.org works best. Yes, it requires an application installation, but the transfers are much more faster and reliable when browser is not involved. And its Android application works nicely on Google TV/Android TV, so I can send files there easily.
How does localsend work exactly? I've read both their website and Github README as well as part of their protocol docs but I still have no idea. How does the initial device discovery work? For file transfer does it use the local wifi, some external server, …?
It looks like they implement something similar to Bonjour [1] using multicast DNS [2]. Not sure if it's basically a reimplementation like Avahi [3] or if it's a slightly different protocol (only skimmed the code [4] briefly).
At the very worse case (NAT hell or something else) they may use a DERP relay. But if you have a cooperative connection or plain local connection it works fine.
There's encryption overhead though, I can't saturate a 1Gbps over Tailscale on M1, while direct connection works (iperf3).
Tailscale looks nice. I acknowledge there is a lot of room for NAT traversal and alike tools. I am quite curious how do you manage network settings across your network. This could have served me well 10 yrs ago.
> Taildrop is currently limited to sending files between your own personal devices. You cannot send files to devices owned by other users even on the same Tailscale network.
I'm using KDE Connect on my phone, tablet and PCs. It works great to transfer files across devices, and adds some other benefits (clipboard sharing, using the phone as a trackpad or a presentation remote, reading SMS on the PC, etc).
Readit News
I thought Bluetooth might be viable, as beacons and GattServers seem to be designed for this purpose. Android's implementation was painful, yet doable. However, after wading into Microsoft's codebase, I suspect it will be slog.
Question: With an agreed upon network name or configuration, and agreed upon access parameters, how much change do you think it would take for FlyingCarpet to instead by used as a semi-anonymous, dynamic membership mesh network?
Ex: A laptop and a phone get near each other, they recognize their proximity, and that they are both offering the known network, they then check for the presence of known filetypes in a known folder location, and exchange small updates with each other. The same with any number of desktops, laptops, or phones that get near each other. If I was in a mall with 11 other similarly configured phones nearby, and 5 people working on laptops, then my phone would call the 16 other devices, and they would each get a file from my phone, and I would get a file from their phones.
If the UI was simpler and more "Apple-like" (hate to say this) I could convince my non-tech coworkers/family/friends to use it.
Also, could you auto detect the other peer's OS? You could skip an extra step and UI element. Do you need it to know which WiFi bandwidth to use?
I’ve moved ~500-800GB via air drop in one go before.
If not, I'd guess that Apple devices maybe come with 2 WiFi adapters inside?
There was an app called "Wifi File Transfer" which would expose a web UI in the local network to download and upload files to the phone's storage.
First I only used it to upload music to my phone (faster than USB1.1 or even USB2).
Then I found out it also works fine when creating a WiFI AP/Hotspot and allowing other peers to connect to it.
Not all of them.
"Airdrop isn't just a nice UI for sending files between people, it allows a wi-fi speed transfer between two [Apple] devices that aren't connected to an existing network of that speed."
More precisely, WiFi Direct allows it.
There is no reason why one should not be able to use WiFi Direct to transfer files between Apple hardware and non-Apple hardware.
But Apple and Google, via iOS and Android, stop users from using WiFi Direct to do it.
WiFi Direct does not belong to Apple, or Google.
https://en.wikipedia.org/wiki/Wi-Fi_Direct
Everyone who buys a computer from these companies should be able to write applications that use WiFi Direct. The chips support it. The buyers own the hardware, not Apple or Google.
Being able to quickly squirt all of that, including photos, to another crew is a literal lifesaver.
Apple Watches used to update over Bluetooth and it would take hours, literally. And someone discovered a trick to turn off Bluetooth to force it to update over Wi-Fi, and then the download took just minutes.
For the server, on Android I use "Share via HTTP". On desktop running a lightweight HTTP server is easy too.
Edit:
Apparently that sounded complicated, here is how I can share a file from my phone to any other phone in the same Wifi.
- Click Share -> Share with HTTP.
- The app opens and shows a QR code.
- Other person scans the code. Their browser opens the file and they can do whatever they want with it.
If you have no Wifi:
- Open QR code for hotspot
- Other person scans QR code for hotspot, then for file.
If you still think it is too complicated, surely there is an opportunity create a simpler UI! From a technology perspective it does not have to be complicated.
This will not work on many public and corporate networks. A common place where you’d want to share.
> surely there is an opportunity create a simpler UI!
It’ll still suck compared to Airdrop. Apple has gone to a lot of trouble to make that work as well as it does. Trying to setup something relying on temporary hotspots will be sub par UX. (And a nonstarter for Apple devices - user apps can’t touch the WiFi settings).
Apple simplifies this stage.
But that was just before they decided everything had to go via their cloud.
Curiously if you used a London bus in around 2005 with bluetooth on you would experience a lot of files being sent to you via ad hoc networks.
With Airdrop, if you are on the moon and meet a stranger there who also has an iphone, you can perform the high-speed transfer of large files.
[1]: https://en.m.wikipedia.org/wiki/Bonjour_(software)
[2]: https://en.m.wikipedia.org/wiki/Multicast_DNS
[3]: https://en.m.wikipedia.org/wiki/Avahi_(software)
[4]: https://github.com/localsend/localsend/tree/main/app/lib/pro...
[1] https://tailscale.com/kb/1106/taildrop
Am I understanding it correctly?
EDIT
> This makes it a great solution for sending sensitive or large files without third-party servers in the middle.
It clearly says the opposite. I don't know where I got that idea from.
There is a coordination server that sets up the initial connection, but after that both devices are connected directly to each other.
There's encryption overhead though, I can't saturate a 1Gbps over Tailscale on M1, while direct connection works (iperf3).
> Taildrop is currently limited to sending files between your own personal devices. You cannot send files to devices owned by other users even on the same Tailscale network.
[1] https://github.com/schlagmichdoch/PairDrop
On my tablet, however, it works flawlessly.