Writing code is fun, but I can't find much of a downside with Bluetooth here. "You can accidentally turn it on" (fair, I guess?) "and it drains battery like crazy" (it shouldn't unless you have a very buggy device) don't seem like that bad compared to Yet Another File Sharing App.
I remember way back in the Android 4 era, my phone and my tablet both supported some "standard" form of WiFi Direct. It worked intuitively (just share a file), was blazingly fast (as fast as P2P WiFi can be), was low latency, and just worked. I used it to transfer media files and backups and it easily beat having to hook up a USB cable to two devices. I was sad to find out this was probably some kind of proprietary interface, because the feature seems to have vanished. It was the best local file sharing mechanism I'd ever used and it disappeared into thin air. Android Beam was nice, but computers and tablets don't have the required NFC hardware to make it work.
I don't expect Apple to play nice with anyone else, but it's time Microsoft, Google, and the various Android manufacturers got their shit together and developed some kind of open sharing system. Google and Samsung already joined forces, but Microsoft seems to have gone off to do their own thing again. We have P2P WiFi for display sharing and the like, why can't we decide on some kind of file sharing protocol here? I don't care if it's SMB or FTP or HTTP, it's really not that difficult a problem to solve. The only issue is that there are hundreds of apps, each with their own protocols and implementations, none of which come packaged with the OS.
Yes, this is killing me. I have a colleague that told me "on iPhones I can super easily share files to someone else", and I'm like "20 years ago sharing files across devices was a non-issue, because we had STANDARDS (ok maybe 17-18 years ago rather). Sharing files wasn't considered a feature worth mentioning because every phone supported this out of the box (well not exactly, so the feature was having Bluetooth). Tech monopolies prefer to ignore standards (looking at who implements which parts of Matter is pretty hilarious in that regard), and killed a whole range of obvious things in the process.
As much as I hate Apple for their repetitive NIH syndrome, Bluetooth has never worked flawlessly, and increasing filesizes made it increasingly maladapted.
The point was that before FAANGs, people were talking together and created interoperable standards. In 2006, Bluetooth for file transfer between phones was pretty nice. Standardizing file transfer in 2010 would have given us file transfer over WiFi P2P, and people would actually use it, and it wouldn't be shipping broken on most devices.
> Writing code is fun, but I can't find much of a downside with Bluetooth here.
Yesterday my son needed to transfer a video file from his Android phone to his school iPad. We tried Bluetooth, but it simply kept failing, no matter what we tried. The devices saw each other and could be paired, but file transfer didn't work at all. We tried sending the same video file to another Android phone, and it just worked on first try.
So, even basic Bluetooth doesn't work in all cases, unfortunately. He ended up recording a video of his phone playing the video... :)
> I don't expect Apple to play nice with anyone else...
This seems to be the problem in our case.
Tonight I'll setup a Nextcloud on our network, this should work properly.
I wrote a similar comment but so far have only received downvotes without any feedback as to why people seem to disagree with me. Admittedly, maybe my position is a bit more extreme, in that I think it would be pretty reasonable to consider applying political pressure or even legislating to improve file sharing and interoperabiliy between devices. I'd prefer it if big tech companies would just come together and implement support for full cross platform file transfers, but I don't see that happening.
My biggest frustration is that there doesn't seem to be anyone with a large platform willing to ask people in leadership at the big tech companies about such features.
In my ideal world: big tech would come together to write some spec, then devices and operating systems would slowly implement and roll it out. And on older devices you could just build a third-party app that implements the same functionality. The goal would be that ultimately you'd have seamless basic interoperability between devices without having to install third-party apps.
Bluetooth is really slow, that's the main drawback.
WiFi Direct is a really great technology but unfortunately it is as simple as its name implies: it's a peer-to-peer version of WiFi. It establishes a connection between two devices, but you need to do everything else (like figuring out how to send files over the socket) yourself.
There are plenty of cross-platform apps that implement WiFi Direct file sharing though.
What I find weird is how easy to use is (was?) Wi-Fi Direct between Android phones and how this isn't a common thing in Windows or other non-mobile OSs.
I have just Discovered Windows 10 have Wi-Fi Direct if you have both Wi-Fi and Bluetooth adapters, and it's as easy as enabling it and right clicking a file to share it. It's a shame this isn't common knowledge nowadays
Microsoft's Nearby Share isn't the same as Android's Quick Share (formerly Nearby Share). You can download an app to get Google's share feature working, though, but that doesn't fix the problem.
The best solution I have found to easily exchange files between devices so far is to use Telegram. It works perfectly for your own devices.
You can have it on multiple devices at the same time (computers, phones,...), there is a special "saved messages" channel for files, it can easily accommodate small to reasonably big files (like GB files), and there is also a webclient that you can use in a few seconds if you are not on your trusted computer.
You can also delete the file once you are done.
The only problem is that you will have to trust Telegram for having you data. But I guess that if you are ready to trust WeTransfer or Google drive, it is not really different.
Yeah same here. Feels stupid sometimes though to transfer a 2GB file from my pc to my laptop through Telegram's servers when I could do it in my LAN but nothing has beaten Telegram's UX for me so far so I always wound up using it.
Taildrop just solve a smaller part of the problem space.
For example, often the target might not be up or connected and you might want to have your file available to all your devices.
The closest competitor to Telegram in term of convenience is email I think.
Just a common use case, I will be at work, and will get a airplane eTicket pdf for a business trip.
I would connect through telegram web to drop it into my saved messages. Then, later I would be quite sure to have it available on any of my phones when being at the airport, and even being able to access it from my personal laptop later for a visa request for example.
Also, a moment later, I could suddenly share it with my girlfriend so that she have all the info to pick me up when I will come back.
In addition I can quite easily search such documents by keywords or date.
Tailscale uses Wireguard which is E2EE and Tailscale clients are open source. I use taildrop all the time, it’s very reliable and not only that, it’s P2P so it doesn’t go through other people’s servers afaict.
My understanding is that to configure your WireGuard tunnels the tailscale saas layer distributes the keys. If so there’s nothing stopping it distribute a key you don’t control.
The hilarious thing is that was what Dropbox was meant to solve.
Like Drew Houston's demos to Y Combinator was copying a file to a given folder on one computer... and seeing it show up in the corresponding folder on another computer. HN comments at the time were dismissing, like "whatever, I can do that with rsync"
I hate how it's gotten progressively harder as the big platforms effectively declared war on local files. Tools like ES File Explorer and WinSCP used to work great, once upon a time.
It is purely because of the lack of static addressing. Probably an entire country's GDP-worth of SaaS products are essentially nothing more than providing basically a proxy to other devices that have to have apps installed to speak their special language.
If I knew your computer's address (and it didn't change) and you knew mine, we could route traffic through the infrastructure we already pay for.
It will solve all of our problems for good and after it's implemented across every ISP, everyone will live in an interconnected utopia without NAT and other obstacles getting in the way of direct P2P communications across any device. /s
It will at least address the NAT problem. Theoretically, if ISPs truly embrace it, it will also open up the possibility of direct P2P communication across most devices on the Internet. Can't remember if there's a standardized protocol for IPv6 like UPnP but if not you can just configure your firewall manually. Of course, that's assuming ISPs allow you to do so.
Tbh, I misread your OP and I somehow got the idea you were talking about NAT. Static addressing is also a problem but a smaller one. In fact, IPv6 probably does nothing to help here, and may even make the problem worse with address randomization (which is a legitimate privacy feature, but still).
If only we had something like AirDrop that reliably worked cross-platform.
Proximity-based sharing just makes significantly more sense than uploading files to some server miles away, then immediately redownloading them back when the computer was two feet away from you the whole time.
I just tried it and it works as expected for Windows <--> Android.
I was using syncthing but this will replace it for one offs.
EDIT: I checked out another app in the comments and their website mentioned that it didn't work with a VPN. I can also confirm that LocalSend works when connected to VPN.
I know that Meta and Google make money from data, but they are also competent, so they can be trusted to at least not get breeched or sell the data to the an aggregator.
If the choice was between 'the competent concentration camp' and 'the concentration camp run by one dude in his spare time', then if the question is 'which one is more likely to feed me', then yes, that is apt.
Pairdrop was posted on HN a little while back and I setup an instance on my home network. Doesn't work everywhere obviously but it does seem to effectively solve this problem within my household.
Syncthing tries to send over the LAN if it's available, and only uses Internet relay servers if it can't establish LAN connectivity. This is why it's (usually) blazing fast. Not sure why the OP thinks this is a misuse of the tool. In fact, it's probably one of the intended purposes of it.
Yep, syncthing is the closest I've found to a simple(ish) cross platform solution. Though when at home, my actual solution is to copy to my file server on one device, then copy from the server on the other.
I regularly have to send files to customers, from a few megabytes to a few gigs. It's incredibly hard.
Mail? Goes to spam.
WeTransfer? Mail clients break URL.
Download from my website? Some stupid browser will display the zip data onscreen.
Send the link through messenger? Messenger breaks the link.
SaaS gallery? Some file managers can't open the zip file.
I've been doing that for two years now. Still don't have a 100% working solution. It drives me mad. Just yesterday I spent 30 minutes sending 3 jpeg files to a customer.
Most webservers have a way of adding a header# Content-disposition "attachment; filename=$1"; that forces downloads. Nginx at least guesses based on file extension / mime type.
FYI - I've also recently run across end users who are likely victims of overzealous IT departments that disable Basic Auth, even on HTTPS connections. Even though they don't do anything to form fields which might contain the exact same data. I don't mind if they break their own domains but the whole Internet?
Firefox used to have a settings screen where you could go file type by file type overriding the browser behavior and setting it to ignore Content-Disposition.
Oh no, I've seen Chrome and Firefox (with a well-conforming web server) loading zip files as if they're pages. The culprit? Intercepting HTTPS-breaking inspection. This is not just in enterprise environments, antivirus companies somehow even justified "HTTPS scanning" as a feature.
When my workplace tried that, I just asked the CISO how they handle the bank credentials of the people that access their bank account at work. I never got an answer, but the system was gone a week later.
in the mid 90s i worked in a machine shop that had a side business where they had catalogs. They were trying to send .TIFF files over 14.4 or 28.8 modems. TIFF files over 10MB, so no floppy (easily.) No CD-R, Jazz/zip.
These days in the same circumstance as you (and they) had, i'd fedex them a USB stick, or optical disc, depending. Because the first time someone said "the web page you linked is just displaying garbage" i'd turn in my tech credentials, because that's probably my server's fault, not the browser. MIME has been a thing for three decades, at least. it sounds like someone tried to use a static html daemon to share a zip file, and it assumes everything is ascii. like it's 19xx and zmodem hasn't been invented yet.
It would have to be mangling both the Content-Disposition and Content-Type headers.
If that's really happening (I have my doubts) and that's a client you want to continue supporting, then the next step would be limiting yourself to SingleFileZ-style ZIP payloads that can be as text/html.
Nextcloud works well for this, and as the files are already on your server you don't have to upload anywhere, you just share the folder, put an expiry date on and send them the url
To add to this, it's reasonably easy to run, and has many different plugins, from a calendar and contacts list, to an online document editor (like Google Docs, except it can be pretty slow and/or resource intensive: https://nextcloud.com/office/), to a simple clone of Slack (https://nextcloud.com/talk/), a mail client (https://apps.nextcloud.com/apps/mail) and other things.
That said, I've had updates (across major versions) break things on multiple occasions, one out of two servers running the exact same version has random crashes and in addition to that the file locking by default (if enabled, but not using Redis: https://docs.nextcloud.com/server/latest/admin_manual/config...) has broken and prevents me from deleting a file that just sits there and takes up a few GB of space. Oh and their Android app fails to upload files if I use the share option, instead of the file picker from within the app.
On the other hand, sure beats storing data on third party clouds and is free, so I'll still keep using it.
And as a bonus it can also be set as a drop box, where customers can send files to a folder of your choice. All the benefits of wetransfer but self hosted.
Yes, sending it is easy. But on the other side, whatever software my customers are using tends to break the links.
I've had that with both mail clients and messenger. Call it antivirus protections, "you're leaving our website" thing, facebook tracking data... Whatever, they will break your links eventually.
I know, it's unbelievable, I don't blame you for doubting me. But still...
I had explored the opportunity [1] to help send files securely based on the Firefox Send fork available at [2]. It proved very difficult to sell with actually no interest in such a product (and I probably sold it the wrong way).
I still use it myself and never had links not usable by the recipient (shared by mail).
I don't have a good asynchronous solution, but if you can do it while on the phone/Teams with them, then Web Wormhole (https://webwormhole.io/) is absolutely fantastic. You both open a web page, you drag a file onto yours and it starts appearing in their download folder.
It's WebRTC based so peer-to-peer, E2E encrypted, with servers only used for serving the client, and for NAT punching.
What you really want is the native iOS or Android version of this (or of any Magic Wormhole derivative), which the wormhole-william people are working on (I think the Android version already works).
Yeah the Android version has been out for a few years[1][2]. There's an iOS target that works as well, I've just never published it to the app store. Every time I start that process I get annoyed at how hostile Apple is to open source developers and give up. Hopefully I can at least distribute a side loadable binary when that becomes a thing for EU users.
Apple's walled garden is supposed to be protected from trespassing, so software can't be required to trespass it as breaking protection is computer fraud.
Every time you hit the web page you have to re-trust that it's not stealing secrets from you. It's not end-to-end secure; in fact, you literally might as well just upload your whole file to that site and just let it handle the wormholing for you.
I tried wormhole.app many times and have about a 60% failure rate because there's an error or the download never completes. Don't know the difference with your link but i suppose i should try it next time
That would be blocked in a lot of large companies. IT blocks common cloud storage urls to prevent employees from storing company data on third party servers.
Isn’t https://wormhole.app/ the solution here? Note I haven’t used it, it’s just often brought up here as a good solution for this class of problem. Is it surprising that the author mentions a ton of solutions but not this one? I would think a deep dive of file sending applications would include this, it’s old enough and well known enough in circles that its exclusion in a comparison of file sending approaches does feel like a bit of an oversight
Here is a list of open source options. This isn't the first time I have shared this on here either. Perhaps this is another sign that web search is failing us.
I've tried using Wormhole and Filepizza from two devices on my network (a MacOS laptop and a Windows PC) and they just don't work for me. I assume the others use the same approach, and would probably also not work. I'm sure there's some setting I could change on my home network to make them work, but I think the point of the article is that we're looking for a way that a) just works, b) across platforms, c) even if you're a dummy like me.
I have used many of these to send files from windows to linux or mac to windows. My point isn't that one of the solutions above is perfect, but that the problem has been tackled in a user friendly way with existing web technologies in a variety of ways. These are very small, often one man projects, compared to something like airdrop for example, and they do 80% or more of what you need them to.
I spent less than a minute searching and found another WebRTC based project.
Imagine what could be built with an actual investment? I don't think the money exists for this type of tech, otherwise we would've seen someone do it in the last 20 years.
Just a sanity check: Did you turn off WebRTC and forget that you did? If you're using Firefox, setting both of the about:config flags "media.peerconnection.enabled" and "media.navigator.enabled" to false disables WebRTC.
UBlock Origin's "Prevent WebRTC from leaking local IP addresses" setting also might interfere even though I don't think it turns WebRTC off. The same applies to Brave's "Disable non-proxied UDP" option for the "WebRTC IP handling policy" setting.
a) Connection from one port of your external IP address to another port on your external IP address will not work if you are behind NAT that is not set up properly to enable hairpin connections.
b) Local IP addresses to connect to may not be provided by the browser to the Javascript code if there's a setting or extension that disables it.
c) Local router can be set up to prohibit traffic between clients (usually wireless devices). If hairpins don't work, you can't exchange any data between such devices without the help of external relay server, as there is no local network at all.
Other than that, WebRTC promises that two browsers can transfer data directly if they are able send UDP packets to each other somehow.
There is also Send.Vis.ee, which is a community fork of Firefox Send. It has always worked very well for me personally. There are many public instances available with varying file size limits and expiring conditions.
Nice thanks. I think the exclusion of some of these is especially egregious because the author identifies three criteria and then says that none of the solutions they explored fully meet all three. But at least from an early glance at least one or two of the solutions you mentioned do, as well as the solution I linked. Which kind of invalidates the entire point the article was trying to make, that there are not good solutions for this. There are, the author just didn’t consider them.
I have used all of these solutions, including the one you shared in the past.
Some of them used to work better than they do now, I imagine with browsers updating and the software going unmaintained, it hasn't left them in a great state. These are small open source projects without funding from what I can tell.
The fact that they work at all is amazing to me, and says a lot about what we can do with a few Web APIs. If only it was worth getting these individuals to collaborate on a web standard API around file transfers, maybe then we would finally see a long-standing solution.
None of them work like Airdrop or Nearby Share. You can't right click a file in the file explorer on PC or Mac and share it. Nor you can open a photo on your mobile photo app and chose share.
The downside of websites like that is that it travels over the internet, so you're throttled by every bottleneck along the way, which can be very painful if you're out and about and your hotspot is suffering 3G speeds. Meanwhile, Airdrop spawns an ad-hoc network giving you gigabit transfers in the middle of nowhere. Personally, if Airdrop isn't an option, I use TotalCommander to transfer over my hotspot network (no internet connection needed)
Not so for WebRTC. We use Snapdrop all the time to transfer between devices, and it just gets the two nodes talking, but the data xfer is peer to peer on our network. Works great.
I don't think a browser is involved with the solution either. The protocol/transport definitely isn't the problem. It doesn't matter. The problem is integration, and solution, is integration.
The tricky bit that makes this hard is discovery. I think Apple does it right. UDP multicast discovery across local intranet, with bluetooth broadcast/NFC proximity for physically near devices that might be on separate networks/locked down. There's the possibility of internet based discovery, but that involves a central authority keeping track of your IP, constant polling, with a nice record of all your devices and transactions. In China, there are apps that use audio, for local discovery, which is neat.
I firmly believe we won't ever have a real solution for the next 30 years. It would require three enemies cooperating: Android, Microsoft, Apple. As is, Apple has this solved. Samsung is gettin there. Microsoft has nothing.
For this I created a public Backblaze bucket, created a lifecycle rule that deletes files after 7 days, created an application key with write privileges but not read ones, then wrote a script that uploads an arbitrary file under a random name so only people with the name will be able to download or overwrite it. The best part is that the file is available under an HTTP direct link, not behind an obscure webpage with ads, so it’s easy to deal with with any tool and doesn’t require the other end to install WhatsApp or Telegram etc, and there is no file size limit (you pay $1.5/TB but it’s fairly cheap if you deal mostly with files <1GB). Now I just wish I could write such a script for my mobile phone as easily.
Now this violates rule #1 (you need an account and you need to pay $6/TB/month for files stored, or $1.5/TB if you store files for only 7 days). For rule #4 you can set the lifecycle arbitrarily, like 1 day, such that the cost of storage is less than the cost of traffic.
No need to give your file an obscure name, or use a public bucket. You can use a private bucket and create a presigned URL with an expiration of up to one week.
Presigned URLs are long and ugly and b2 requires an extra API call to generate that, so I tend to prefer not to use them. The other reason for obscure names is so that you can't download or update files that you don't know the name even if you have the upload key. I know it goes against common sense security practice but compromising convenience can mean compromising security in many cases. The thing is to make sure your scheme is rigourous.
I recently started using KDE Connect because I was fed up with the way I had to send photos from my Android phone to my Ubuntu desktop. I usually did that by email, or in some rare cases I plugged a USB cable in to connect.
KDE works over Bluetooth, I guess, but it was super fast for transferring around 20 to 30 photos at the same (maybe more might also work, didn't try that).
But the most important thing was that I could look at the thumbnails of the photos before marking them for transfer. This process was always very slow with an USB connection, because it was always trying to 'thumbnailize' every photo in the folder (which were 100s or 1000s). Picking the right photos by obscure datetime-name is not fun.
That's the #1 solution for devices under my control.
For the rare cases, where I need to transfer personal data to/from corporate devices, I just use https://webwormhole.io/
On windows I had to explicitly allow the executable in the windows firewall. I didn't get any popups or warnings that it got blocked. After that, it worked fine
Tailscale recently added local file transfers called Taildrop https://tailscale.com/kb/1106/taildrop
This really solved this issue for me, right click a file and select the receiving peer and it just appears instantly on the other device.
I would assume that limitation is because it's on the roadmap, but they want a different UI for it, or more control, or to see how beta goes with just your own devices, give some time to think about how it should work, etc.
Because they've had to specifically put that limitation in place, no way they don't realise it could be useful.
I created an automated installer to provide this functionality on KDE Plasma using Dolphin this morning to emulate the experience of sharing via TailDrop on Mac for Linux.
The filesystem where my files reside should already be a fully-distributed filesystem covering all the devices I own, right from the moment I buy and enroll them.
With that precondition, my file is already where I need, and any physical bit shuffling is just a detail managed by the OS, using whatever connectivity is already available (or prompting me to "please connect cable type X between devices Y and Z for N minutes" if devices are out of sync).
Isn't that exactly the model of Gdrive/OneDrive/DropBox etc? Except they might not do any LAN transfer optimizations, but that is minor implementation detail
I don't think those come even close. Some blocking considerations:
- They are a bolted-on "magical part" of your filesystem. If you manage your files anywhere outside of the magical field of synchronization, they're invisible (e.g if your file is in the "Downloads" folder, but that folder is not synchronized by Dropbox, then you won't find it from any other device.)
- They are not distributed filesystems. They are a central filesystem (on their premises, outside your reach) and a smart replication strategy. You don't get a say on data sovereignty, and your data lives on rented disk space.
- Trying to operate on your files is dependent on which device you're using. If you're on a computer, you get first-class local files in first-class directory trees, that you can manage with the usual semantics, provided you have enough free space in the physical disk of that device. If you're on a phone, you download copies of files (and pray they get uploaded if you change them in phone), and almost no way to manage the directory tree aside from the application itself.
>The filesystem where my files reside should already be a fully-distributed filesystem covering all the devices I own
I'd rather not set up the possibility for a single software bug to destroy all my data at once. Even if you have good backups, there could be subtle data corruption that you don't notice until it's too late.
Let's take a real life example: My Android GPS (OsmAnd) records GPX files on my phone storage when I'm out on a trek.
How should I configure Google Drive/OneDrive/iCloud to expose those files transparently in my computer (a linux box at home) as they get created?
And more importantly, why should I have to configure anything at all? The idea I'm advocating for is that those are my files, and so they should be in my (distributed) personal filesystem by default without me having to set anything up.
I must be missing something, but right-click -> share already works just fine?
Share with kde connect, select your windows, linux, iOS, android whatever device, done.
The only restriction is that both devices are connected to the same WiFi.
Why are you looking for cloud solutions for a local transfer?
If they're connected to a vpn that allows client to client communication that also works you just have to specify the ips in the setup screen since auto detection won't work.
Yes. As you need kdeconnect installed on both devices to transfer your data from the one to the other, it is trivial to also transfer data back once the connection is established.
The app is available for Linux, Windows, macOS, iOS and more.
I recently discovered that the Files app on iOS/iPadOS can connect to SMB servers, so my solution is to just use the NAS that I've already got. Windows, MacOS, and Linux can also connect to SMB just fine and I'd be shocked if Android couldn't also do this.
Rule 1: There are user accounts, but they're local to the NAS. I think it meets this one.
Rule 2: Setting up the NAS is likely out of reach for many non-technical users, but using the files app and doing stuff in it is perfectly reasonable. Partial marks here.
Rule 3: It's consistent in the sense that every platform uses its native file manager to connect to the NAS and manage files. Managing files on each platform is different, but you're already dealing with that difference. I'm calling it a pass.
Rule 4: The NAS is the junk in the middle, so this is a fail.
I tried File's SMB support but found that larger (100+ MB) transfers fail for no apparent reason (1). Third-party apps' SMB support is much better - I had success with Readdle's Documents, Goodreader, and most recently FileBrowserGO.
My slow-to-moderate internet speed may play a role; however even connecting to my laptops SMB share over a wired connection was fraught with issues.
1: the failed but in-progress transfers often stick around with no way to remove them. They're gone after restarting the device, though.
Which tends to be my go-to solution for file transfer between devices, it shares the current directory over HTTP. Not perfect, since HTTP makes downloading directories rather cumbersome, but at least every device that can open a website can download stuff.
Assume that both devices are behind a different NAT with no inbound ports publicly accessible, which is a very common scenario - e.g. a phone behind a cell provider's carrier-grade NAT and a computer on a firewalled corporate network.
The median hacker would likely have something available with proper internet connectivity, they are substantially different from the median user.
But many of the solutions mentioned in the article and comments will effectively use some "third place" to link the two devices, e.g. how magic wormhole does that.
Of course, this is a known way to do it for hackers.
But the article clearly mentioned boundary conditions, among two are violated by the netcat trick:
* It needs to be useable for a non-technical person
* Its flow has to be consistent across platforms
Besides having access to a terminal, netcat must be installed and hosts accessible, ports open etc. Not what is usually the case and especially not advisable when you operate on the internet level and not on protected local networks.
I would also wrap it in a WireGuard tunnel, especially if doing it over the Internet, unless you want your fellow hackers intercepting everything you're transferring.
P.S. I love WireGuard, it's easy to set up and allows you to use protocols with no encryption (or bad proprietary encryption) securely.
True, but in my experience WireGuard + unencrypted file transfer protocols is faster, not to mention more flexible. But if you already have SSH set up, that's a good option for sure. I used to use SSH port forwarding extensively before I discovered WireGuard.
The difference is small. Mine runs as a server and accepts transfers one after another, it's a bit more useful, because I send files regularly. It doesn't accept a transfer if the client fails authentication. Sometimes I send files between random machines ad hoc, having one tool (one file) makes it easier to setup, and not all have netcat installed, especially windows, but some linuxes too.
F-droid has an android app and the cli runs on Linux, Mac, and Windows. Super pain free. It's not a synchronization solution, but sends stuff pretty easily.
This. croc is like a better magic-wormhole (available via python pip, apt, other package managers) I switched to croc after transferring large files over terrible wi-fi. No way to resume a failed magic-wormhole session, whereas croc does it automatically.
computer-1$ croc file-i-want-to-send.txt
Did you mean to send 'file-i-want-to-send.txt'? (Y/n) y
Sending 'file-i-want-to-send.txt' (555 B)
Code is: 1234-some-diceware-passphrase
On the other computer run
croc 1234-some-diceware-passphrase
You can also just drag-and-drop a file onto the executable icon and it will pop up a GUI letting you do the same thing. Transfer is encrypted, no account needed.
The bigger issue is on Apple and iOS, the "regular user" doesn't often interact with individual files outside of the app. Even at my work (US airline), there have been recent restrictions added to the workstations so you can't just plug in a USB thumb drive and transfer some files (honestly a no-brainer). But for many people, much of their experience learning about using computers comes from work. If you don't regularly do it at work, how would they learn how to do it outside of work?
command from a command line on whatever device I need to send from and then hit it on a webpage. You can run that on an iOS device even with something like Libterm
I understand why AirDrop doesn't get full ticks here, but I have to say it has saved me hundreds of hours over the last few years transferring literally anything from phone(s) <-> laptop(s) <-> laptop(s) <-> phones(s) at the drop of a hat.
I was forced to go digging for a solution that supported Mac, iOS, Android and Windows. Localsend is available through the app stores and on github. I haven't had much occasion to use it yet, but here's another to add to your lists: https://github.com/localsend/localsend
This looks impressive. Much less clunky than the Syncthing's interface and doesn't look as buggy as KDE Connect on my first try. The real test would be moving my 95GB DCIM folder from Android to Windows. Let's see how that goes.
Localsend works really well so far, no issues with device discovery. I use it within our (heavily firewalled) intranet for offline file transfers between machines; particularly where you can't just scp something.
I'm also a big fan of LocalSend! I've tried several tools in the category of "easy cross-platform file/text sharing over LAN," and LocalSend really stood out as the most polished option.
Most people should run a static HTTP/1.1 webserver (after port forwarding 80) on their home PC so they can dump files into a directory to share them by sending the http://your.ip.address.here/directory/ link via email or whatever.
When you use directories and files your OS itself is the natural interface and everything just works.
Most people with computers can right click and folder and hit share. SMB clients are built into any modern computer OS and various mobile devices (and apps are available for those devices that don't have it enabled by default).
HTTP is clunky, unintuitive, and requires typing in IP addresses. It's not a natural interface to file sharing at all.
It uses WebPush notifications to set up a WebRTC data channel. So full E2EE with no website-run server in the middle (unless you need TURN). The actual domain is just a static site.
It is similar to a lot of the other WebRTC based solutions but it works better for me because the push notification means that I only have to navigate to the site on one device. Then on the other I can just click the notification. And other than initial setup there is no need to manage pairing codes or similar each time.
I mostly use it for between my phone and desktop. But has also come in useful for transfering files to and from my partner's Steam Deck and various other situations.
(Although last I checked it was having trouble on Chrome due to some weird interaction between the Chrome push server and the CORS proxy on Deno. It used to work and Firefox doesn't need a CORS proxy so that still works. I should probably get around to filing a bug against Chrome to enable CORS on their push server)
I'm truly sick of how difficult it is to copy files between devices in different ecosystems. It makes me grind my teeth that emailing/WhatsApping attachments has become a default for people literally standing next to each other.
No, we don't need more proprietary protocols like Apple This or Google That. We've got scp, sftp, Bluetooth, all manner of secure connecting and tunneling methods, all of which can be made easy to use and secure.
Apparently, I can't Bluetooth a file from my Android phone to my partner's Apple phone because apparently Bluetooth is insecure and Apple have hobbled it on iPhones. What a crock. Fix the damn protocol or make a new one that's open. It's anti-competitive and user hostile to do otherwise.
Yes, there are the various wormhole and filedrop services, and good for them. Unfortunately they sometimes don't work on corporate/academic networks.
People completely misunderstand Bluetooth. It's a fingerprinting and tracking protocol. A legend says that sometime somewhere someone was able to reliably pair devices with it.
For getting files off my android phone, I like "Share via HTTP".
https://f-droid.org/packages/com.MarcosDiez.shareviahttp/ it is easy to use, and leaves nothing behind (it also doesn't use up space on the phone to stage the files to be transferred, like proton drive apparently does, which can matter if your storage is almost full)
Only between desktop and one mobile phone though. I find it mildly inconvenient not to have my messages synced between two mobile devices. It really breaks the magic of cross device usage.
* send to “saved messages” in telegram
* use gmail drafts for text sharing, remove after copying, when airdrop not available
* python server for local things
I've been thinking about this problem a lot recently... Honestly, I wish we could apply a bit of political pressure to force major tech companies to implement basic device interop and file transfers.
In the year 2024 you should be able to seamlessly transfer files across devices wirelessly regardless of operating system or manufacturer.
AirDrop is pretty close to ideal, but it's limited to Apple's platform. I don't really care about any of the underlying details, I just want to have a simple way of sending files between devices without having to enable complex configurations (cough SMB, WebDAV, etc.) or tinker with anything. This could be achieved, it's not a pipe dream.
Why isn't anyone lobbying for such an essential feature that could make everyone's life slightly better?
There are no technical barriers to implementing this. There's just no political will.
Edit: I think the ideal solution would be to have some sort of spec that device and operating system vendors could implement, so that workaround stop being required at some point. Then for older devices you could build an application that implements the same functionality.
Bluetooth file transfer is not accessible enough for non-technical people? I mean I guess you have to mark the device you want to send to as "discoverable". If anything the real problem is that it's not very fast, but that's only an issue if you are sending particularly large files. This is still often my go-to solution aside from Tailscale's Taildrop feature.
>Bluetooth file transfer is not accessible enough for non-technical people?
It's incredibly difficult. Do you have any idea how "non-technical" these "non-technical" people are? I know people that use phone every day to make calls as send messages, take photos, browse Facebook, read emails and they could not send an email with a file attachment to save their life. Asking that kind of person to:
1. Enable Bluetooth and make device discoverable
2. Enable Bluetooth on another device.
3. Pair the devices.
4. Find an option to send the file
5. Accept the file in another device.
6. Wait for the file transfer to finish.
7 (bonus). File transfer failed for some reason and you have to start again.
We did it all the time before smartphones, 'bluetoothing' ringtones or images (especially if lucky enough to have a 'cameraphone') to each other.
I suppose it depends what you mean by 'non-technical', maybe our parents couldn't have and we were 'tech-savvy' in the way that children are, but this was normal, what everyone did, and of course many in 'non-technical' work now, didn't study CS, etc.
You elongated this by assuming Bluetooth is disabled on both devices, which is not the default state on any OS I am aware of. The actual step list looks like this:
1. Enable Bluetooth discoverability on the target device.
2. Share file over Bluetooth on source device.
3. Accept the file transfer on target device.
You don't need to add extra steps for things like "wait", that's the same for any kind of I/O operation such as "copying a file". It's also extremely silly to add something like "Find an option to send the file". On most operating systems, it's just not that hard. On Android it's in the normal "Share" popup. So this amazingly difficult and highly technical step is to press "Share" on a file and select Bluetooth.
I could also make turning on a computer sound like a tedious seven step process if I wanted to be an asshole.
>which is not the default state on any OS
Irrelevant. It could be intentionally or accidentally disabled by the user.
I don't know why you are so annoyed, but I know for a fact that average non-technical person is incapable of sharing files over Bluetooth on their own, and this probability of incapacity increases with age.
I'm annoyed because it doesn't really matter, misrepresenting the situation by adding steps that aren't really there doesn't strengthen the case, it makes it sillier. I would guess it's more likely that people don't know to use Bluetooth for sharing, more than they simply couldn't figure it out. And to be fair, why would they?
There are a lot of things where simply knowing to do them is a large part of the problem, rather than a literal inability.
This shows the joys of writing software for yourself (and your friends if you want).
I have an admin panel on my website for dumping files into S3 that I can then download later.
There are a million solutions out there, but simply hosting a file upload/download service that syncs to your own S3 bucket is for me my favorite solution. It's user friendly to me only, it's unusable for everyone else.
Not necessary anymore, you can message yourself in WhatsApp now. They even sent me a notification in that regard. (That is recent though and I wish I'd known that (clever) workaround before this was possible)
Recent? Unless you mean the notification, sending yourself a message has been possible for a long time. Just to make sure I know what I'm talking about I checked the conversation history with myself and the earliest messages are from 2016.
Bluetooth technically does work - but I don't think I'm ever able to get anything about ~40Kbps. It has similar issues to Wifi in that the OS abstracts it to such a degree that it's nearly impossible to see what's going on and to debug issues
- Is it switching to some low power mode?
- Is it falling back to some old version of the protocol? Why is it slow?
- It shows it's transferring on my laptop, but on the phone is shows it's still connecting.. why?
- Oh look, it just randomly "failed" in the middle of the transfer.. okay, why? Where do I find more info and debug/fix it?
I've not been able to find a good way to work with it. Maybe I need to bring out Wireshark? Maybe Ubuntu is misconfigured somehow.. If the issue is with my Android phone then I'm probably totally screwed b/c there are only a couple of toggles in the Android menus
( and I have basically identical issues with KDEConnect and other methods )
I like to use ShareDrop.io [1]. It's peer to peer, auto discovers in local networks but works globally with shareable links. Only downside, because nothing is stored it's not asynchronous.
I'd like to suggest another alternative: `adb` (just platform tools) which has the `push` [1] command
push [--sync] [-z ALGORITHM] [-Z] LOCAL... REMOTE
copy local files/directories to device
--sync: only push files that are newer on the host than the device
-n: dry run: push files to device without storing to the filesystem
-z: enable compression with a specified algorithm (any/none/brotli/lz4/zstd)
-Z: disable compression
I am surprised to not see Jami ( http://jami.net ) mentioned here yet. It is a GNU project and is fully cross platform. I use it to send files and messages between my devices, as easy as Telegram or Whatsapp.
I just installed it on Windows and then downloaded it on my iPhone. Can't even link my iPhone to my Jami account created on Windows. iOS side doesn't ask me to scan QR code and when I enter my pin and password it just says my account was not found.
EDIT: I removed my password and instead of relying on the app for scanning the pin, I used the iOS built-in camera app to scan the pin and copied it to the app. Now it works. But that was poor experience nevertheless and I wish it was better designed.
In an ideal world any hosts have an IPv6 global and any human have at least a domain name, with relevant subdomains for hes/shes own devices, a simple thing also offered to non technical users by ISPs in the form of a homeserver-router like the real one they offer but not crap, without violation of GPL, without doing their development just to milk data from users etc.
So in an ideal world anyone can share files directly, can serve their own blog, participating in decentralized socials like Usenet, exchange messages in a decentralized manner like emails (not to be confused with WebMails frontends common today), having direct IP2IP (well, personal domain to personal domain) VoIP calls with or without video and so on.
Such ideal world is there technically, it's not utopia technically but it's utopia socially in a society who have mostly chosen ignorance for the many and abuse of their ignorance for few.
Unfortunately I think it would take governments to start waking up and treating internet access as a public utility. Even then they'd have to compete with ad companies to get the right people to do the job.
I think governments like the large availability of OSINT data from big tech, in a technically sound IT such giant collections would be far harder and limited... Similarly the effectiveness of modern propaganda would be far limited.
The power of IT is the power to store, analyze, craft, manipulate information, if you give it to the most than the most can be Citizen not just slaves...
https://pairdrop.net/ works well enough for me, but it still requires internet unlike airdrop... I wish these bluetooth transfer things were just magically cross-platform. Maybe someday.
I setup Samba share on my LAN. It works well enough for my purposes. It's not super smooth as not every app let's me open a file directly from the network and I need to make a copy first.
This has been my solution too. I have a vpn into my home on all my devices, so even away from home I can typically rely on it.
As a side note, for Android I've been using (and can't praise enough) Material Files [1]. It's the best simple file manager I've used that has built in samba support.
AirDrop or pbcopy/pbpaste on the command line (piping through base64/tar) between my own devices or Synology NAS to share with someone outside or Google Drive worked well enough for me.
As a Syncthing fan and user I'd say setting it up is non-trivial for a non-techie. Not hard, just not easy either. Once it works it works like a beautiful charm though!
It would be nice if Syncthing supported the concept of moving files though - i.e. that it should seed a file to other peers and once it hits the target seeding level, delete it locally.
Needed copying a pdf file from iPhone to PC. That was absolutely impossible! Tried USB, WiFi and Bluetooth. None of the built in apps or sharing services allowed copying the file over.
I bet at some point there was entire team of people in Apple each paid >>200k USD with the goal "Make impossible a transfer of a single file out of an Apple device to a non Apple device, and for every incoming file from non Apple device pretend you don't know where it was saved and what it is even. Make it look like an incident."
XMPP is great for that, since I adopted it a while back, it's just been a breeze to send files around. With a usual setup and Gajim or Conversations for instance you can decide if you're sending that one file to all or a specific device(s) (i.e. resource), it's really neat. Hosting my own ejabberd server was also the easiest setup experience of my self-hosting life, can't recommend it enough.
for a long time I've actually really wanted the plumber [1] here but a more networked and cross platform protocol for it. I really just want to be able to plumb urls from my android phone to Linux desktop or vice versa and have it work according to the plumber rules.
Syncthing works on Android, and for between-own-devices cases fits well. Typically, you just have to sync Download (for Android at least it's where 99% of useful files go) across your devices. It's a bit challenging for an average human to setup though. I do however share the frustration: basic operations (not just sharing) with files are stupidly complicated, and became worse with newer Androids.
I have an USB stick with both an USB-A and an USB-C connector. Works flawlessly (if you ignore the fact that files are hated in the Android echosystem)
A comparison like this is not complete without Windows file shares or SMB.
Sadly, despite pretending to try hard, it doesn’t pass the “requires expert to setup” test, it’s super easy to either accidentally lock down everything or accidentally open up your network to the world. It also fails the platform-consistency requirement, outside windows or outside your home network it is very frustrating.
With external clients I serve the file locally, password protected access and encrypted file and then call them and watch them download. Then I confirm that they got it and stop serving. This is safe than to trust it to a third party service and I can monitor access. Sharing local port via ngrok is easy enough and Python comes with a http server that can serve a folder.
I figured I'd try to solve this some years back.. registered "itcopiesfiles.com".. then promptly left it in the not-even-started side projects list ever since.
What would work for that? How about:
1. One of the parties goes to the site, gets a code/link
2. Other party goes to the site, enters the code/link
3. Either party can drop a file/folder to the page
4. Data simply piped from one request to another by the server
SSH requires to have shell access on the receiving end, that renders it unusable in most situations. Rsync can in theory do anonymous file offerings, but it's not a shell one-liner to get it up and running either.
Warpinator works really well between Linux systems, it's like magic
But add windows computer and it's a little bit of a mixed bag, you need to open ports, jungle the firewall and .. the magic is gone, the USB stick is out.
on every OS - windows, linux, android, iOS - it's like a 20% chance that it will connect or send the file if one of the clients has closed and reopened or disconnected momentarily. you have to close and reopen both clients.
TailScale sends cross-platform. Or just self host Nextcloud and have that on all systems. Look at Nextcloud AIO. So easy. I use both. This is a solved issue for the most part. Also solves the file sending to others, as well as file requests.
Now, universal cross-platform copy/paste? Ha. I’d love that solved!
I never used Syncthing but I miss it from the list. Does that not fit this? I mean if you do the initial setup on the non-technical persons device, its basically just copying files into a local folder. The other device grabs it as soon as its online or in the same network right?
Yes because privacy MATTERS, and principles to only use open source and contribute back, even if its "only" a bug report matter too. Encrypting single files and also their names is a pain in the ass even for technical people. Its too many steps and just does not flow. If you have some kind on encrypted container you have one big file that you need to re-upload over and over again to share what is in it. A solution that is encrypted by design and the server never ever knows what is in the file it transfers to different devices is the way to go here and Dropbox and all the shitty for profit services to not offer that AFAIK.
I have this problem all the time, so I wrote a simple web app to handle file transfers between computers on my local network: https://github.com/fastily/dumb-file-drop
Dropbox is a lifesaver for getting around iOS’s horrendous way of
dealing with files. If I need something on another device just send it there. Also useful for taking photos of receipts for tax time.
I got excited here, but after reading through and getting to the conclusion part my excitement dropped. Also, as the author states, if you're not technical person it's a hassle.
I haven't had much luck with this on ios devices, everything else i have something that will work - matrix, misskey, etc. But realistically, i solved this 10 years ago or so by buying a Synology diskstation. I don't have access to it outside of the house, but that's why i run nextcloud in a DC, too.
For a long while for stuff like sending drone footage to a friend while on my cellphone only i'd use syncthing, but it was very fiddly and hard to use in the winter, and i never got a "here's your link" thing, which may be fixed now. So i'd have to edit the filename and remember it, and then type the whole FQDN and URI to send someone a link.
Nextcloud handles this much better. Misskey also handles this better, although i don't use it for large files. But at home, synology. There's clients for nearly everything including smart TV devices, and between computers i can use NFS or CIFS. I can even link https:// download links locally.
Let's just remember, folks, we had fully p2p video chat on windows, and then techbros started buying up huge portions of ipv4 because their antics were getting subnets blocked at routers, and now i've never (and i mean not one time) been able to get an open ipv6 port to accept traffic on a home device. Additionally, i barely remember what life was like without CGNAT, as i've been behind it for a decade with 3 ISPs.
So i don't really care if you or your grandparents or kids can transfer files easily. use a USB stick like i do with my in-laws, neighbors, and whatnot. You did this to yourself. Enjoy your fb messenger - and email spam, though!
-signed by someone who had /28 on GTE.net DSL 26 years ago
I realized that the only reliable way to copy files between Windows, MacOS, and Linux is FAT32 formatted USB drive, assuming you have USB-C/A adapter available. Cloud object storage if you don't want to split the file into 4GB pieces, take the extra step to setup the clients, and upload speeds are acceptable. Between iOS and Android there is no local solution without PC in the middle and at least one MacOS machine is required. Most seamless is FTP server, but no free and acceptable FTP app exists for either. Very disappointing for an era when "AI is replacing and firing everyone".
I stand corrected! I've had so many problems with it (preventing PC from sleeping, problems minimizing at startup, etc) combined with the completely non-native look-and-feel that I've come to associate with Electron that I just went with it. Next time I'll double-check to be sure, thank you for the correction!
Well, you either transfer it directly from A to B using a protocol that both ends support such as Kermit (what we used to use back in the day for copying files from bulletin boards using modems), or FTP, or SMTP (yeah, e-mail attachments), or via some intermediatory server or device such as Google Drive or a USB stick (floppy disk).
I guess nowadays the only files that most non-techies care about are photos and videos on their phones, so solutions specific to those work, or indeed the ubiquitous e-mail attachments.
weird i can still send myself msgs on whatsapp... - i will never update again... who else is gonna send me messages :s
Oh, yeah , and that's my main way to share files too these days... and don't forget to share music as documents before whatsapp ruins it >.> - so it's still a bit tricky!
It's not the same thing. You can't right click a file on your PC or mac and click send, nor you can open an image on a photo app on mobile and use share.
Well, one can use a conventional torrent client. Half of the popular ones have some kind of “share mode” to automate the creation and link exchange. Or use a dozen other existing file sharing tools, including plain netcat.
The problems are elsewhere:
a) “Simple enough” is a moving target. Some time ago, users were expected to state their needs, find convenient tools, figure out how to use them, and be happy that their problem is solved. Nowadays it is proclaimed that user is an idiot, because the idiots don't actually choose anything, they do what someone else decided for them to do, and it's Good for Business.
b) People don't know which solutions already exist (looking at the author here).
c) Smartphones are deliberately crippled to create the market for 50 different bundled and third party file sharing apps and other reinvented wheels, with data and money trickling to the platform owner. In addition, rat race never ends, and the developers must update their apps constantly. Say, there is some ancient BTSync installer for Windows. It's rough, but it works. I'm not saying anyone should use that, but you can still transfer files that way. Can you use smartphone apps from ages ago in the same manner? Most likely not (and race organizers make sure you can't). It's quite like constantly resetting the MMORPG server to restart the money and activity flow into its economy.
"Copying a file across your own personal devices is still painful."
No. I have never had an issue with Dropbox or Discord for simple file sharing.
For encryption I use Mega with Signal for key sharing.
MegaSync is fantastic for files you want to sync between everything and has builds for all the popular distros. The fact that he doesn't list Mega is worrying to say the least.
He's a nuDev creating a solution in search of a problem.
I keep trying to remind people that one of the real unsung advantages of a cli is how easy it is to tell others how to do something. If I never have to describe an icon to someone again, it will be too soon.
The OP talks about transferring from a PC to a phone (and vice versa). I have no idea how to use scp on my phone or how to move a file from my PC to my phone with scp.
Honestly, if you can teach me how to do that in less than a minute, I would (no sarcasm) really appreciate it.
where the only trick part is how Android managed storage, but it's just more letters (/data/user/0/com.arachnoid.sshelper/SDCard/<path>).
Once I found Termux I embraced it since it's a nifty linux thing straight on my phone with it's own configurable sshd and it's exactly the same as above except with a different path and lots more options.
That's fair, the duopoly on the mobile platform is such that you are only allowed to do what google or apple deigns to allow, so I suppose one must take it up with them
It also requires running a ssh server on the PC, and the even harder issue of having an externally accessible IP address that will allow ssh connections to the PC from the internet - I can do the former but I'm not entirely sure if the latter is even possible with my ISP.
Only if there is direct connectivity (or router has port forwarding set up), there is no firewall or port is open, one computer has ssh server running, another one has ssh client jnstalled, you know the username on remote computer, you know password or have ssh key set up, and if copying from remote machine, you know exact filename or at least a location. None of that is given, especially if one of the ends is a cell phone.
I agree. The state of mobile tools is severely hamstrung by the fact that the overwhelming majority of the ecosystem is on closed platforms
I'm not sure how you would propose to solve the other problems, such as "the computers can't communicate directly" or "you don't know where the file you want is" but that doesn't seem like a problem with there being proper tools available
Right. So my point is that if we define a non-technical user as "someone who doesn't know how to do the thing yet", and any amount of teaching them to do the thing is thus implicitly deemed an unacceptable cost, then the problem simply has no solution
As the defacto I.T. support man for family and friends of varied skill levels… sometimes it’s really daunting trying to get them to do things that seem very intuitive to the technically experienced. I’m not saying we should just give up ok trying to show people new tools but I can empathize with the terror of even imagining handing a terminal off to some of these people, hah! A simple GUI goes a long way for people who don’t, for example, know how to write a file path or don’t know the difference between a forward slash and a backslash!
Nah, you just make your interface use verbs the target audience is already familiar with. They might not by familiar with command line text verbs, but they're probably familiar with point & click or drag & drop verbs.
Having just last night gone back and forth with multiple screenshots and careful explanations to guide someone through importing a picture from email to the ios photos app… maybe I’m lazy but it’s just exhausting. I agree that with effort it’s do-able, but it IS tiring :)
I remember way back in the Android 4 era, my phone and my tablet both supported some "standard" form of WiFi Direct. It worked intuitively (just share a file), was blazingly fast (as fast as P2P WiFi can be), was low latency, and just worked. I used it to transfer media files and backups and it easily beat having to hook up a USB cable to two devices. I was sad to find out this was probably some kind of proprietary interface, because the feature seems to have vanished. It was the best local file sharing mechanism I'd ever used and it disappeared into thin air. Android Beam was nice, but computers and tablets don't have the required NFC hardware to make it work.
I don't expect Apple to play nice with anyone else, but it's time Microsoft, Google, and the various Android manufacturers got their shit together and developed some kind of open sharing system. Google and Samsung already joined forces, but Microsoft seems to have gone off to do their own thing again. We have P2P WiFi for display sharing and the like, why can't we decide on some kind of file sharing protocol here? I don't care if it's SMB or FTP or HTTP, it's really not that difficult a problem to solve. The only issue is that there are hundreds of apps, each with their own protocols and implementations, none of which come packaged with the OS.