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.
It's a very cool idea, but the first barrier that comes to mind would be that when the clients join the hotspots, they don't have internet access, so joining the network would mean losing internet, for laptops and phones without cellular data. I know the LocalOnlyHotspot API I use on Android doesn't offer internet tethering. I'm not sure how possible it is to ensure that on Windows and Linux devices that host hotspots. Also, the device that offers the hotspot in Flying Carpet is pretty much acting like a normal WiFi access point in infrastructure mode, so a real mesh network would probably look a lot different.
Thanks. Those are the kind of issues I was worried about with a superficial glance. The general idea looks tempting ("send files to nearby devices"). However, dropping connectivity every time would probably be a deal breaker. I was hoping you might be able to connect for like 10-20 seconds, grab a few kB of files, and then continue on your way, having a spotty, partial connectivity to other devices while wandering the above mall scenario.
Thank you! Yeah, obviously the UI is a weak part. I'd like to improve it eventually but as a one-person project I don't want it to have as minimal of an interface as AirDrop. With all the ways transfers can go wrong, I want that information to be in the user's face so they can submit issues and I can help debug easily.
And no, it can't detect anything about the other device until they're on a WiFi network together, and that can't happen until it knows the peer's OS because it has to know whether it or the peer should be hosting the hotspot. Windows has precedence, then Linux, then Android. (The iOS version doesn't need to know the peer's OS because iOS and macOS can't stand up a hotspot programmatically anymore, so it always has to join.)
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!).
I have been using Resilio Sync between my Mac, Synology and an android e-ink tablet. Everything was working fine when I set it up, then a few months later when I wanted to transfer something I discovered that Resilio Sync on the Android e-ink tablet had forgotten about the shared folder. Trying to set it up again is a pain. I would prefer AirDrop over Resilio Sync any day of the week.
Resilio Sync is also incredibly slow when the two devices are not connected to the same network. Like kb/s slow.
It’s better now that you can choose only to expose it to contacts, and only enable it for “everyone” for a limited time. I seem to remember in the past you could leave “everyone” enabled indefinitely, evident anytime you stood in a crowd.
> I seem to remember in the past you could leave “everyone” enabled indefinitely, evident anytime you stood in a crowd.
er yes, Apple seemingly eliminated the "everyone/forever" option because it was being used to slightly-anonymously[0] spread stuff the chinese government didn't like [1]
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.
That this is possible, and allows to maintain a dual connection to an AP and an ad-hoc connection to another device for AirDrop, sounds amazing. Now I want to learn more about that technique and where/how it can be applied to non-Apple devices!
Honestly, I've been having excellent experience with BT (and headphones) with modern devices.
For example, my Lenovo T14s (2023 AMD version running the latest kernel) connects to my (5.2 version of BT) headphones really well. Similarly, my android phone connects to the same headphones and whatever device sends data, that's what I hear.
Similarly, my Steam Deck connects to two of the headphones I'm using (Sennheiser and Apple Airpods) seamlessly.
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
I agree, it's not a radio protocol and I wasn't trying to imply that it was. The person I was responding to posited it might be one and I pointed them to the protocol that's used without explicitly correcting them on that point.
"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).
It is standard practice to enable this these days in public networks and it is so common that even consumer grade shit router now come with an option to enable.
I am not sure you understand. You click share, then Share via HTTP, the other person scans the QR code, they have the file. Setting up the server is no effort at all.
Only if you are outside without Wifi you have to do another step, setting up a Wifi hotspot, but that is not hard. And in most situations I have been in both devices were in the same network anyways.
Which of the steps that I described required advanced technical knowledge?
Edit: Ah maybe you thought setting up the server is an additional step. It is not. Share via HTTP is the server. It runs directly on your phone. The URL points directly to your device.
None of that is necessary because you are not exposing anything to the internet. We are still talking about local sharing. Android does not have a firewall so there really is nothing to configure. But if you think it cannot be possible, try it for yourself.
All your traffic can now be captured. DNS requests will be logged. Some traffic might be redirected. When will the connection be closed? What if someone shows you a different QR code, and you're not that tech-savvy. For example a phishing webpage which asks for the user's password. Many many many people will still just enter their single-password-for-everything.
What if the QR code is a deeplink to an app.. for example to a conversation on or whatever. Or maybe someone was previously logged in into some account.
It's literally click in the share icon and choose "Share over QR".
The device then will do the "run a server with the file, create the QR Code for access, display it". Your mum has no need to learn how to run it, just how she doesn't need to know anything about how airdrop works to use it.
It's the same difficulty. They used techy terms because we know that's what's happening, but your mom doesn't need to know those terms or anything like that.
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.
I was kind of kidding, but I was also kind of intrigued by the idea. My instinct is that it would work in a vacuum, but that is just a gut feeling. But I also could not think of why one could not.
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.
I see your point now. Here no phone with a Contract is locked anymore, and certainly no Bullshit like "locked Functions" that you have to pay extra for like Tethering.
So it's not a huge hassle to quickly spin up a hotspot.
But Android offers a Airdrop-Like-Feature natively called "Nearby Share" but what still sucks in my POV that there is still no Cross-Plattform-Solution between iPhones and Android out there
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.
No, free software is different than "does not cost money". You can pay for free software. For example the OS of my TV (not a smart TV but still) is free and opensource, yet I paid for it when I bought my TV.
I bought it 10 years ago, it cost me less than 50€. And every interactive device has an operating system, no matter how simple it is. Just to accept inputs from my remote and displaying menus to configure lightning/colors/volumes/etc., it needs an OS.
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).
Sharing files is great but what I’m looking for is simple QR code ephemeral chat. Like if a want to copy a link or password between my phone and some device. Tried a bunch of different ones that I’ve found on search but they’re clunky and kind of work.
I should check the code first, but my guess is that this is built using webrtc which was primarily created for realtime communication (including audio and video).
So my guess is that such feature can be easily added.
By the way, if you're using chrome, you can take share text directly via the clipboard. So that you can share from your phone, and immediately paste it in your computer, or vice versa.
By using kdeconnect (it has an Android app and a gnome extension), you have this done automatically. This means that you can copy a text in your phone, and paste it in your computer, as well as the other way around.
Interesting idea. The QR code part is good I think. I would be interested in what you tried, why it was clunky, ideas of how to make it usable. thanks!
My need is actually when I’m out somewhere fairly remote where there’s no WiFi Internet connection, but there’s either 4G or 5G data, the phones are running iOS and Android and are in close physical proximity with each other. Is there something that works for this device-to-device to send raw data with minimal friction and maximum security (don’t want the app to be sending the data elsewhere)?
Pretty slow, but you can still use Bluetooth transfers. Other ways are to have an WiFi hotspot on one of the devices and use one of these alternative apps.
Some apps out there are even capable of opening a small HTTP server, so you can technically serve files on tether.
Would be cool if we sometime would get https://github.com/seemoo-lab/opendrop as an android app (but it would only work with rooted devices). This would allow to send and recieve files to iPhones from android via Apples Airdrop protocol.
Kind of cool. UX not as smooth as p2p file sharing with airdrop on Apple devices, but it works well enough.
I couldn’t get the “local network” feature to work though despite devices on both networks. Probably missing something. Had to send the link to myself.
I am still missing why people are so crazy about airdrop. Sure, it seems nice, and is nice to interact with, but all my stuff is already in the cloud and i don't seem to need to share it very often with people around me. What are some of the use-cases you personally use airdrop for?
But neither of these implementations are going to provide this functionality, because of lack of development kits, right? So in the end people would just send it over some messaging app, which scales nicer, or create a shared album, which also scales nicer. Because smashing phones in group of 10 people might get tedious.
The functionality described by the person you are replying to is part of all Apple devices. It also works without being on the same messengig app and without having the recipient in your contacts in the first place.
Another example for AirDrop use cases is transferring large media files to another device. People use that all the time for moving recordings to their editing computer, for example. Even if you have all your stuff in the cloud (which not everyone does) - it‘s much faster to do a local transfer than uploading and downloading something like a high res raw video from a modern phone.
You don’t need to implement airdrop as separate functionality.
If you are capable of sharing a resource in a message or album, it is also automatically shareable via airdrop. iOS treats them all the same via the share sheet.
I have my local sync'd to my cloud storage and just pull it down if/when I need it. I'll just email/text people around me if they don't have airdrop compatibility.
For videos, yeah. When I'm in a room with friends, and one of them is already connected to their TV, it's much quicker to airdrop a large video file (say, 500MB) than it is to send it up to the Internet and have them download it. Aside from the better bandwidth, it's also much faster from the time I tap "Share" to the time it's appearing on their device.
For gifs or a funny photo or whatever, yeah I'll just text it.
I'm trying to learn how to use Tiktok (yes, I know, I'm sorry) and other social media and cross-posting isn't really great and some platforms pretty much force you to post from mobile devices or vice versa (Tiktok, Instagram for mobile, LinkedIn for desktop web), and I need to pass source videos from mobile to editors on PC and back and forth for posting on the different media.. It's a big of a mess, I'm kinda sure there are crossposting services out there already, but it works for me so /shrug!
One thing that it beats the cloud / centralized sync on is because the connection is direct between devices when the initial transfer is completed the file is completely there on the other device. With a cloud type of sync you do the transfer twice. I've seen stack up on large media or with the structure of cloud services pricing making it expensive depending on how your workflow is setup with inside and outside parties. For example, Dropbox deduction from all parties' storage limits not just the sharer.
You can also point Syncthing at a local sync of Dropbox or Google drive and then forward the files to other recipients from that for some purposes.
Sounds much more painful than dropping them in iCloud / Google Drive / Dropbox, as you have to send, accept, save, switch to app, upload instead of just going to the app, select file from cloud storage, upload.
Especially when you might want to upload from multiple devices.
Yes I do. I'm often moving files between two Macs and sometimes my iPhone. I have a few important documents and maybe 100 photos backed up in my free google drive storage, everything else is stored locally.
Email/Text has very small files size limits so that's not an option for me.
