← Back to context

Comment by eigenspace

1 day ago

My problem is that all these alternatives require the devices to be on the same local network.

One beauty of Airdrop is that it creates and handles that local network automatically under the hood (as far as I understand). So you could be out on a hike with friends and Airdrop something.

The workaround I've found after switching to an Android device has been to teather my connection to my friend's device, which ends up creating a LAN that Localsend can work through, but this is not as nice an experience.

https://mbarlow.github.io/thinair/

Device to device transfer, just a static github page.

gh repo: https://github.com/mbarlow/thinair

Creates QR codes for each device to scan for webrtc. Android to android will do an audible chirp that lets the devices know to switch from qr code mode to opening the camera to scan each others codes. Tested android to apple and working, the audio chirp doesn't get caught by apple. Just wait and eventually the qr code will dissolve to allow scanning step.

Just threw this together. I was playing with audio handshake using bird-like chirp "songs" or old school modem between smartphones. Fun putting phones together as they send audio frames and confirm to start transfer, but unreliable and slow to handshake. I would like to cleanup the flow to improve. I've started using it for sending files between iphone/android/pc without having to deal with apps, emails, accounts, etc. blah.

  • This is using webrtc and speeds are slower than a physical USB I get 3-4MB/s instead of local network speed of 30MB/s due to browser browser implementation bottlenecks. I needed fast local network sharing of files over 5GB and tried a lot of approaches and speed doesn't budge more than 6-7MB/s .

    Also you don't even need a server atleast for now in chrome webrtc transfer can work over a file:// in firefox it doesn't. For signaling you could even use free peerjs tunnel or other when user is connected to internet and otherwise fallback to this QR or offer code sharing. This will become so useful if browsers eliminate those bottlenecks.

    also even in localsend speeds are limited usually to my internet speed for some reason.

  • Whenever I need to use something like this it's because the device isn't mine, which makes this so much better than an app. Would be cool if there was a text message option, and a bit of server so the second scan wouldn't be required. Pretty funny how simple the concept is though.

  • Doesn't seem to work for sending files from my Mac to my Android - I scan the code on the phone and....nothing happens? I tried sending via FF/Safari/Brave and receiving on FF/DDG. No idea what am I doing wrong.

For true crossplatform p2p the closest I have found is FlyingCarpet [1].

But it is not super reliable or friendly.

[1] https://github.com/spieglt/FlyingCarpet

Airdrop is also pretty weird: sometimes it can’t find other phones (probably when a previous transfer failed silently in the background). Also, it had some issues searching for contacts when there was no mobile/Wi-Fi connection (tried to send photos to another phone in the mountains). Sometimes it could just freeze and not work… Apple magic here isn’t really useful.

I think the initial handshake for Airdrop is through bluetooth and then both devices peer through wifi. Not sure why there isn't a solution for Android, perhaps there are hardware limitations, I don't know the bluetooth stack.

If we would have good operating systems, perhaps this would be easier and more widely spread. Otherwise the solution has to come from the device manufacturer.

Indeed, Localsend only does the last step of what Airdrop does. With Localsend, you need to:

- Create an ad-hoc Wi-Fi network on one device.

- Connect the other device(s) to that Wi-Fi network.

- Now run Localsend.

The first two steps are a bit of a drag, and the fact that Airdrop handles it is what makes it so frictionless to use.

  • Right, the first two steps are what make AirDrop, "AirDrop". This isn't an alternative at all if it requires both devices to already be connected to the same WiFi.

    AirDrop is fantastic for sharing files with people you don't know/just met - if we have to find and agree to join the same wifi before we interact we are no longer talking about the same feature.

    If Apple's AirDrop implementation had required people to join the same WiFi first, the feature would never have taken off the way it has among non-techy users. I'm still today mildly surprised I can use AirDrop as a verb in conversation and most of the time the other party knows what I mean.

This. Localsend may be very useful for a set of devices you control or influence. The USP of Airdrop is ad hoc sharing with people you don't really know. Classic case is meeting strangers on holiday and you want to swap some photos of the trip you're on. One or both of you doesn't have data or time to install anything, or it's just too hard to persuade someone they should install random app. Pairing Bluetooth or setting up local networks is way too convoluted and time consuming.

With Airdrop you have trivially easy, "just works" sharing with people in proximity. It works great between iPhones and Pixel phones now they support it. It just needs support to spread to more Android devices.

  • > With Airdrop you have trivially easy, "just works" sharing with people in proximity.

    Funny enough, I encounter so many problems trying to share things via AirDrop with friends, family, and even my own Apple devices that I just tell everyone to install LocalSend and I find that things work better.

    I’m not sure why that is, because AirDrop used to work pretty well for me. But it’s been an exercise in frustration more often than not for me.

    (Obviously, LocalSend works only as long as everyone is on the same network.)

    • I've found it very often falls back to sending over your internet connection even if your cell reception sucks. No idea why. People on a previous HN thread talked about solutions

  • setting up local networks is so trivial compared to forcing everyone to buy an Apple gizmo.

    • The real choice though is between (a) buying an apple gizmo and not having to set up local networks; and (b) buying a non-apple gizmo and having to do that.

    • True. But I mean these are photos (from strangers that you aren’t even willing to exchange phone numbers with?). It is a really non-essential feature anyway, so most likely everybody who doesn’t have an Apple device skips it.

      1 reply →

Not only that, but with iOS 17.1 or later, AirDrop transfers will continue to work if you go out of Wi-Fi range during the transfer. It seamlessly switches to an Internet-based relay.

  • Which, in my view, significantly decreases the value proposition, as there is no way to deactivate this feature to my knowledge (at least not without also opting out of other useful features under the "Handoff" umbrella).

    A typical Apple feature, dreamed up by engineers that are presumably not aware of the existence of metered data plans...

    • You can disable it, actually.

      Settings > General > AirDrop > turn off Use Cellular Data

      That said, I don’t really see why you would disable that. It’s only a backup method for when the peer-to-peer connection fails. Unless you are sending huge files on a regular basis, I wouldn’t expect it to be worth disabling. Also, most metered plans I’ve encountered just cause your connection to be very slow after you hit the data cap.

      If you are on a plan that automatically charges you excessive overage fees without warning and there is no other choice, then my condolences.

      1 reply →

Speaking of ad-hoc communication channels that do not require shared infrastructure: I like the idea of https://github.com/divan/txqr which sends data using animated QR codes. An ultimate guarantee of physical proximity. The bandwidth is not comparable to WiFi 6, of course, but no OS support is required.

I think nowadays on Android it's called QuickShare, and it works. But I believe the fragmentation and awareness is a part of the problem for Android.

Iroh is a relay protocol for peer to peer transfers over the Internet so it doesn't have this problem, check out my other comment here about wrappers around the protocol for sending files, Sendme is the one I use.

https://news.ycombinator.com/item?id=47935026

Airdrop has not felt reliable to me all the time, and completely fails on anything larger than a picture or short video. Especially if you are storing your files on iCloud and the pictures and videos don't live on your phone.

Been using Localsend to transfer bigger files between phone / laptops, never fails or has trouble finding a device, or stalling.

That's why we worked very hard to create the ultimate, nothing held back tool and recently launched it. Works across any device/user/platform.

UI, CLI, Local network, over the internet, anything. P2P + E2EE.

https://zynk.it

Feem is the only reliable one I've found that doesn't rely on being on the same local network

It works on iOS and Android

I am usually able to coerce a Localsend connection by using a WiFi hotspot on the target device.

Usually, but not always.

  • I literally said that in my comment:

    > The workaround I've found after switching to an Android device has been to teather my connection to my friend's device, which ends up creating a LAN that Localsend can work through, but this is not as nice an experience.

I've recently started using blip, which works very similarly to airdrop after the initial pairing has happened. The devices do not need to be on the same network etc.

Wireguard VPN to your home network, and then you can do anything

  • "Check out this alternative road vehicle I invented: it works on most surfaces except it can't drive on inter-city roads."

    "You could fix that by builing a rail track and using a train."

  • And everyone you ever want to share files with locally also has access to your home VPN?

  • That's an even worse solution than the hacky workaround of just teathering my internet connection.

    The whole point of these solutions is to not have to transmit data over the internet, it should work over a local dynamic connection.

If you're on a hike you can get on the same network by joining your friend's phone WiFi hotspot.

  • I literally said that in my comment. I also said it's not as nice an experience.

    • Whoops, totally missed that. Maybe Localsend could include some "discover" mode where Wi-Fi hotspot connection happens automatically?

  • I'm honestly surprised that WiFi Hotspot doesn't isolate hosts, after companies like Meta have been caught running servers inside their apps and connecting to those to track users.

    • I was too when due to network problems at our last traditional LAN-party (WC3, CS1.6 etc.) we used the hotspot feature of one phone to get everyone on a local network. I was skeptical and assumed the PCs wouldnt be able to see each other but lo and behold: it worked flawlessly!

Yes exactly, that's why another RCE which will be found in Airdrop, if found by bad actor. Will be pretty fun to watch.

Last RCE in Airdrop, could be made into worm, it was found by whitehat, luckily for Apple there are still people, which are willing report exploits for little money, so billionaires can enjoy their life on yachts.

[flagged]

  • >It uses a time-sliced channel-hopping mechanism so the radio can serve both infrastructure WiFi and the direct peer link simultaneously.

    This seems like such a basic solution that I'm surprised that it isn't required by any of the mainstream standards before WiFi Aware. I wonder if this was some sort of a patent issue or similar.

  • It is entirely possible to inject (unrelated) wifi frames while being associated to a BSS without violating the existing 802.11 standards. That’s why Apple is able to implement AWDL on standard compliant wifi hardware.

    However the path towards this type of interoperability would likely go through additional standardization via IEEE 802.11* and the Wi-Fi alliance. At which point Apple will need to implement and support the new standards. There is no need to reverse engineer AWDL to meet the new European interoperability requirements. What is needed is for wifi chipset OEMs to implement such standardization. Something pretty routine of them.

    It can be expected that Apple will also maintain the proprietary AWDL in order to support their legacy devices.

    • AFAIK, Wi-Fi Aware / Neighbourhood Aware Networking is basically the "standardised" version of AirDrop, and as of 2025, iOS's Airdrop transparently inter-operates with it.

  • AWDL is such an amazing technology, it's understandable that Apple wants to keep it only for their devices as it gives them a noticeable advantage for quick stuff sharing.

  • > which is a proprietary peer-to-peer layer that runs alongside your existing WiFi connection without dropping it. It uses a time-sliced channel-hopping mechanism so the radio can serve both infrastructure WiFi and the direct peer link simultaneously.

    Maybe a network nerd can chime in - is this implementation so difficult that it's unrealistic we'll see an OSS version?

    • I think the thing that makes an OSS implementation more difficult than iOS/macOS is the friction involved.

      Say you've got an android phone, windows PC, and a linux box, and you want to be able to quickly drop files from each one. unless we get some kind of cooperation across all three platforms at the OS level, you'd at minimum need to install some kind of client into each system - when the nicest feature of airdrop is that it's baked into all of Apple's OSs, in my opinion. even if it worked exactly the same way, but had to be installed, I think it would see less use - and there's no real way for a single OSS project to do that across multiple OS platforms, to my knowledge

    • The physical layer part really isn't complicated, and most Wi-Fi chipsets have supported something like it for over a decade now.

      What's tricky is to specify and get everybody to implement the layers on top of it, including device discovery (frequently offloaded to Bluetooth for efficiency reasons), user identification (Apple runs a PKI for this) etc.

    • Not an expert on mobile development but I doubt an android app has the low-level access needed to the wifi stack to do this.

  • There is an open standard for that which is included in Apple devices since the iPhone 15. google implements it since the pixel 3. It’s called NAN. There are no WiFi cards available for consumers to buy which expose that as part of their firmware sadly. But wpa_supplicant has implemented part of the standard.

  • This is misinformation, including most of the comments here, the majority of phones from 2014 support Wi-Fi Direct, and simultaneous group and station mode (2 BSS, yes even different channels). Even most Wi-Fi chips generally not just smartphones for a very long time. They stay connected to your home network.

    When Quickshare drops your Wi-Fi connection, its not Direct anymore, that's just soft AP from an error, and if that doesn't work, it fallback to Bluetooth. Bluetooth is used for provisioning as well.

    The only reason why many apps don't use it is because of buggy implementation, some phones require a full restart after using Wi-Fi Direct to fix connectivity issues, even Motorola's own product line with Smart Connect use it only with certain models, despite having Wi-Fi direct due to poor implementation (can be forced). They even have a white list of supported adapter for the Windows app since direct is used as well, can be unofficially force enabled for Mediatek based adapters (rare on some laptops).

    Back in 2016 things were much stable on Android phones with Wi-Fi Direct, even with old Blackberry, there were many apps including file managers that used it before it was essentially dropped, even for onboarding/provisioning apps like HP printers...

    Apple's Airdrop success is about gaining traction, in the era of Wi-Fi Direct or other methods, most people were not aware of such features, as it required an app to be installed, they used email/messaging, even when Airdrop was first introduced and preinstalled, it took years for the average person to use it.

  • > It uses a time-sliced channel-hopping mechanism so the radio can serve both infrastructure WiFi and the direct peer link simultaneously.

    This is really nothing special as 802.11 implementations go, as it's pretty easy to do as long as you can control the physical channel for at least one side.

    Many Windows, Linux, and Android devices have been supporthing this for years. It's usually called something like "simultaneous AP/STA mode".