Not the fort-knox implementation it claims on the tin.
'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?
'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.
> 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).
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.
If you can call a purely apple designed protocol as Interop. Its no different to the lightning connector. Apple designed it, and trademarked it. If you want to play ball you need to pay apple a licensing cut.
EDIT: I have just seen they have recently introduced matter support for iot devices. This is a big step in the right direction!
Nearby Share isn't locked down and, in fact, works just fine with zero Google involvement. Google only needs to be involved for limited device visibility and all the phone number stuff that entails.
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
> Still hoping for some alternatives that can do ad-hoc communication, without any network infrastructure.
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.
You’re free to swap files via regular Bluetooth with an app that supports it.
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.
I'm not sure that the benefit really pays off. AirDrop doesn't need network infrastructure but it does need a wi-fi adapter needs to support active monitor mode (it's extremely common for hardware to lack support for this).
The requirement for network infrastructure can be worked around by creating an ad-hoc wifi network.
If you don't have a network connection, you can setup an adhoc hotspot on any Android 9+ (Settings > Network & internet > Hotspot & tethering https://support.google.com/android/answer/9059108) or iPhone (Settings > Personal Hotspot), then connect to it using any WiFi-enabled device.
# Linux
hostname -I
# Mac
ifconfig
# Windows
ipconfig
Start the file server, and then navigate to it using the web browser of your choice on any device connected to the WiFi network (no need for a client application).
chmod +x upload_server
./upload_server
Navigate to the server's ip address (indicated by the hostname -I command you ran earlier) port 8000 in the browser of your choice and upload files using the web UI or directly via curl:
curl -X POST --data-binary @file_to_upload.txt http://192.168.1.X:8000/uploaded_file.txt
Then download the file to another machine or mobile device either from your web browser or via a commandline tool:
The most awesome thing about Airdrop is when you can find the other device, and even more magical if you can do that on the first try: you can send files without being on the same network or heck, you don't even need to be connected to the Internet at all. That is neat.
9/10 times they haven't set the permissions to receive files through airdrop. It used to be open, but that was a huge security vuln. People could just airdrop whatever picture they wanted to all the iPhones on an airplane for example
There was also a certain amount of regulatory pressure brought to bear; Hong Kongers were using AirDrop to great effect in outwitting the authorities during the 2019-2020 protests
That's 0/10 for me: I know I have the correct permissions set up with my friends (because we can usually Airdrop each other), but sometimes it just spuriously does not work.
One thing I've noticed when AirDropping pictures to my wife is that the recipient needs to have their phone _unlocked_. That was definitely somewhat confusing when I first started using the feature.
Had this exact thing happen tonight. I wanted to airdrop some photos to my MacBook, worked from my partners phone but my phone just wouldn’t send them. My phone and laptop could see each other in airdrop but they refused to send / accept the photos. Ended up texting it to myself in iMessage and opening that on the MacBook.
Universal clipboard is pretty great too. It's another thing I wish was just an open standard that all the things supported, not just the Apple ecosystem.
I get a lot usage out of related cousin feature Universal Control, which is the best KB/mouse sharing implementation I’ve used. It manages to feel almost identical to a physical connection even over WiFi, which nothing third party has been able to swing… Synergy, Sharemouse, etc need all involved machines to be connected to the network via Ethernet to pull that off.
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'd never reflected on the irony of these features being called Universal when they only work on Apple devices, but the 'just works' nature really does feel good.
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
I hadn’t encountered KDE Connect before, I might check that out for MacOS to Android. It looks like they’ve done the best they can on iOS, I’m spite of how locked down it is
There could be a standard protocol describing how to authenticate and talk to a server, and get notified. It's not that different from chat protocols.
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.
I once had a specific device that wouldn’t airdrop to anything. Beyond that one device, it has always, just worked. Instantly. First try.
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.
Airdrop is very nice when it works. Modern apple hardware has a second wifi modem for an ad-hoc connection so it can be faster than normal wifi as well.
But Apple only.. makes it much less useful, even for “Apple people”.
Technically yes, it's a virtual device, but not all wifi hardware is capable of running two networks at the same time, Apple carefully selected the "usual" hardware to support this.
Almost all Wi-Fi chipsets released in the last couple of years support this.
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.
Has it ever been reverse engineered and reimplemented?
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.
But Airdrop for me has been a hit and miss. When it works, it's awesome. But when it doesn't work, there's literally not much I can fiddle with to make it work.
Absolutely. My wife stopped sending me stuff over AirDrop because she can't see my phone half the time. So she just sends me stuff via iMessage. We both have the latest iPhones with the latest iOS.
I’m noticing that a lot of the times my airdrop between my new iPhone and iPad isn’t working anymore. I blame iOS/iPadOS 17. Maybe will be fixed in 17.1 ??
Phone-to-phone airdrop is slow. Unless sending video, the messages app will typically outperform the UX and delivery speed of Airdrop for the person sending the file, which is really the only one that matters.
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.
I've been using localsend, mostly without issues. This thread has made me discover pairdrop.net and I have to say it's miles better. I've switched all my devices over now. The iOS integration with the provided shortcut + permanent pairing, in particular, is really good.
Have you tried clearing cache? (I've configured the server to be a bit more aggressive about caching to improve load speeds, but JS bundle updates should be available instantly.)
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.
I actually have switched to Localsend from Pairdrop. My experience is that is Pairdrop is slow especially compared to Localsend. This is while hosting the application on my local network.
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 haven't compared performance, as it's not a bottleneck for me. A 70mb file took a few seconds. Localsend could very well be faster, being a native app.
I don't know. After discovering PairDrop too, thanks to comments here, I've been testing it out to see if it could replace Warpinator [1] as a means to send files & directories between my PC and my Android phone when I'm at home.
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.
You should know that WebRTC is not ideal for this use-case, it has inherent performance and discovery issues. All web-based solutions are flawed until hypothetically the browsers and/or WebRTC step up their game. Fine for a pdf or something, but try it with large files and you’ll very likely have a bad time.
I must say LocalSend seems pretty great (even though they’re a “direct competitor” to my app https://payload.app/ )
Lots of reasons to self host things for this privacy is a big one but owning a service instead of renting means you don’t need to worry about the landlord or service provider raising prices or kicking you out.
Does it let you share files between Android and iOS phones without requiring an app to be installed on both devices? I don't mind installing something on my phone but I can't force other people to install it too.
I think its a bit of a stretch to think that an app would be able to send a file to someone elses phone without them installing an app to manage the file storage and security.
But you still need to be able to send the link, so the receiving party needs some way to be able to receive the link. It is then either some form of local messenger or ... an app. So, yeah, the receiving party needs an app, if the app is not build-in into the OS like Airdrop in iOS.
The receiving person can be sitting next to you so you can share via the sound of your voice or showing them your phone.
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 URL is an IP and a port, so it can be typed by hand. Each connecting client needs explicit approval in the app, and then gets the list of the specific files that have been shared using this method.
It's ridiculous to think people will find it easy type out URLs and that too IP addresses along with a port. It maybe fine for HNerds, but definitely not for others. Shows hows much people in this site live inside a bubble.
It's absolutely fine for a normal person that an advanced feature requires you to type 4 numbers that are on average 2 digits long, followed by a 4-5 digit number. You do not need to understand what it is, and you do not need to memorize it. People are used to typing in their much longer credit card details flawlessly, so there really is zero argument here.
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.
You are definitely gonna mess typing this up. A few dots replaced with commas, the colon replaced with semicolon. And remember, most people don't have enough patience to retype the address once it didn't work.
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.
Your argument makes no sense: for a normal person, a credit card number is 16 random digits (in some places more) + 3 random digits (the validation code) + a date + a name - a vast amount of data incomprehensible to the average user that must be copied flawlessly. Compare that to an IP and port which is on average just 8 digits + 5 digits.
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 maybe coming from a place with high computer literacy, but what I have expressed is what I see in my surroundings.
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.
The point is that computer literacy is entirely irrelevant as it is safe to assume that the average smartphone-owning person is entirely capable of copying text and numbers without meaning to them much longer and more arduous than what is demanded for a local IP.
> 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.
> 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.
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.
> Payments happen mostly through apps here. So people don't have to type numbers.
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.
That is nice. I'd probably just use python to share a directory from termux instead.
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.
Not many other ways to do it... not relying on a common network is a desirable thing if you ask me (say to share photos with friends while camping without Wifi). At that point, a hotspot wifi network is the only solution I can think of.
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.
Apple has airdrop and android has nearby-share or whatever it is called.
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.
Yes, yes it does. You can specify "share by link" instead, in which case you get a HTTP server URL. In this mode, you approve each pageload in the app.
Last week, at my girlfriend's place she couldn't make AirDrop work to display a video on the TV so we ended up using a HDMI cable after of ~30 mins of no luck. Yesterday I went over and the same thing happened only that she mentioned that I'm a bad influence since it worked that last two times when I wasn't there.
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.
I use LocalSend to get pictures from my iPhone onto my work laptop. It’s very simple and straightforward, and does exactly what I need it to do with minimal setup.
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.
Something's broken with the nixos package of this - it lists it at https://search.nixos.org/packages?show=localsend, but trying to install it just throws `error: attribute 'localsend' missing`. Other packages work just fine.
The discovery looks like it might be another way to track devices (besides all the usual ways). One of the fingerprints is the `fingerprint` attribute. The protocol spec is unclear whether and when that can be recycled:
Even when using certificates, the protocol puts the `alias` separately in the discovery message, so clients will have to try not to let that be spoofed.
(But they can still be spoofed in ways client can't detect, especially if humans verbally verify by alias).
I have been using localsend on all my devices. Of course when I'm out and need to share files with a friend's phone (mostly Android) I prefer to go for Nearby Share. But when you're at home, you have all kinds of devices. In those scenarios, I found localsend to be a perfect choice. Native app, no browser (visit this url/ scan this QR code) shenanigans. Simple transfer over the local network. Simple client for Linux, Android, Windows, iOS, MacOS and most importantly good transfer speed.
I wanted to make something like this, but using Bluetooth LE. Then I looked at the Bluetooth spec and implementations realized why Bluetooth applications are so unreliable (other than Apple device to Apple device). It’s really hard. Plus every OS has their own incompatible API, with some parts missing or inaccessible for some reason.
The practical solution to “share files in physical proximity” ends up being just use Apple everything.
Sadly, this whole discussion demonstrates the stagnation of pro-consumer innovation because of the smartphone duopoly.
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.
Yeah, it's really useful! There's this fork called PairDrop, and it's more convenient, you can pair two devices or create a room by entering a code (or scanning a QR code), and that works over the internet too. It's slightly more complicated, but worth it for the features.
https://pairdrop.net
I used KDEConnect daily, but across several devices and networks I've noticed that find file transfers regularly get interrupted and "fail". As is par for the course for networking errors on Linux systems, it's completely unclear what fails. But in the end I've found KDEConnect is only suitable for sending small files.
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 really wish the bump team was never acquired by google. I use to love the ease of just tapping your phones together and immediately sending a file or whatever else across. Made transferring to PC a breeze too just by tapping the space key.
Since we're all talking alternatives, I thought I'd point out KDE Connect. Available on all platforms and allows transferring files locally. I often use it between my laptop and android. Great software.
"LocalSend is a free, open-source app that allows you to securely share files and messages with nearby devices over your local network, without needing an internet connection."
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.
Messages – yes. Files – no, unless the devices can't connect to each other directly. The only problem I see with this setup is that you can't use it without Internet connection. Perhaps sending side could advertise via mDNS in this case?
> 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.
Yes, thank you for the correction. Sloppy wording on my part. What I meant was the rendezvous happens over the internet.
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.
Yes, the "setup" messages via the Mailbox Server will be over the internet 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.
Has anyone attempted to combine all of these desperate open source p2p file sharing solutions into a single app?
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.
(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).
I disable mobile internet on the phone, turn on hotspot and tell friend to connect to my phone. Then let them scan qrcode from serveit app, which will open web server address in browser.
Click on file you want to download.
Does not use mobile internet or outside wifi.
It is fascinating to see so many open-source alternatives trying to find a solution for P2P file-sharing, with no sort of inter-op possible, just like Apple's AirDrop and Google Nearby Share are incompatible with each other.
OSS projects try and bridge the gap. There’s NearDrop for receiving Google’s Nearby Share on MacOS, and opendrop for sending Apple’s AirDrop via Linux (There’s also an android app that you have to build yourself that does the same, though I can’t remember it’s name).
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).
This is similar to magic-warmhole[^1] but has the added plus of being written in golang, which means one doesn't have to install multiple packages, just one binary. Thanks for sharing.
I tend to use ssh or https for that. ssh and sftp clients and servers are available for all kind of devices/OS. Both are easy to use or instruct how to use.
The point of Airdrop is that the devices don't need to be connected to a mutual wi-fi network or to know one-another's IP addresses. They just need physical proximity. It's not for sharing data with established contacts; it's for cases where you need to pass data to people you're meeting for the first (and probably last) time, without any setup.
You just have to configure hotspot on your phone and there you have it. Still easier than asking someone else to install an app, especially if that person doesn't have access to mobile data.
And if it is short textual data it is more easily shared with a qrcode.
"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."
'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.