7 ms·

> What (...) happened to easily sending data, over the Internet And for mobile phones - without internet is similar, unnecessarily hard. The other day I was hi

> What (...) happened to easily sending data, over the Internet And for mobile phones - without internet is similar, unnecessarily hard. The other day I was hiking with friends, and wanted to share a .gpx file with the route, at some spot with no cell coverage. I thought: "I 'member, bluetooth can send files". Well, we spent good 15 minutes trying and miserably failed, that's no longer possible in the name of "security". So I had to wait for cell signal to come back and send the file via whatsapp. To someone standing right in front of me.

Varriount 2y ago
Huh, I wonder what the problem was. I semi-regularly send files between my Windows laptop and my Android phone. I do recall never being able to get that functionality working properly with a Mac though.
- francescovv 2y ago
  That was between two Android phones, with receiving phone being "oppo" or some such, with stock firmware. Receiving phone would see incoming file request, ask user to accept, then error out with "unknown file", and no way to actually save it. I've sent files via bluetooth from lineageos to lineageos, no problem.
  - Varriount 2y ago
    I could totally see it being something stupid in how Android manages file associations or something. The default file managers tend to be fairly crippled and only actually show a subset of files present.
    - actionfromafar 2y ago
      Perfect irony would be if the receiving Android attempts to check the incoming file against some kind of Internet service.
  - AshamedCaptain 2y ago
    It also possible it just dropped it silently in the Downloads directory. Otherwise ironical that all of this behaves like the 90s PalmOS which could not store a file unless a program would accept it.
nvarsj 2y ago
Pretty easy with iPhone+AirDrop. Just bring your iPhones together - it asks if you want to airdrop something, select file, done.
everfrustrated 2y ago
On Android builtin as Share -> Quick Share/Nearby share Available since Android 6 (c.2015)
- sandyarmstrong 2y ago
  Have you tried it? It's horribly slow.
  - HeyLaughingBoy 2y ago
    I use it all the time. I guess I'm just patient :-)
  - ssl-3 2y ago
    I've tried it. I've had it be horribly slow, wickedly fast, and also absolutely fail to work at all. The wickedly fast method seems to involve the two devices forming an ad-hoc WiFi network -- just for themselves. 802.11ac/ax is pretty darned fast when there's no competition, on a network with exactly two nodes, and when those two nodes are separated by only a couple of feet. IIRC, this is not the default mode of operation.
ssl-3 2y ago
Sometimes, I work with bi-directional amplifiers and distributed antenna systems that are intended to improve cellular coverage inside of a building where there may be little or none of that. I have a fairly expensive meter at my disposal to use for planning things like this, which analyzes different cellular carriers by frequency, and can output (messy, and with unescaped commas for notes, but eventually-fucking-usable) CSV files of the results -- with GPS coordinates of the measurement location. This sounds amazing for a person like me in this line of work. But it is not amazing for a person like me in this line of work. (As a preface for the rest of this, remember: This meter is a tool that is meant to be used in areas of limited or zero cellular coverage -- places where outside RF is problematic for whatever reason.) 1. The meter has a Bluetooth interface that connects to an app on a pocket computer. (This part works fine, usually, except the app often doesn't background properly and silently dies if the user uses their pocket computer to do some other task, which might be fine if the problem was ever reported. [Haha!]) 2. The meter expects the pocket computer to have an Internet connection, so it can use that to upload its findings to The Clown. (This part often cannot work, because the whole fucking reason any of this is happening is because cellular coverage is shit inside of a random building.) 3. The meter expects that the pocket computer will provide GPS coordinates, even though it is intended to be able to be used indoors -- without network connectivity, or perhaps even in a Faraday cage. And while modern pocket computers are very good at providing some location data by various means as long as there is internet connectivity or GPS-esque data, all of them fail at this when there is neither Internet nor GPS available. It produces an error [Haha!] when there is no location information available. 4. It does not provide useful errors. It provides errors, but they aren't specific at all and do not promote productive troubleshooting or workflow. ("Oh, there was a problem with your measurement! [Haha!]" is the singular error.) 5. Sometimes, it will even produce an error [Haha!] but record the measurement anyway -- and without recording the error. 6. It stores nothing locally. When an error happens [Haha! Good luck!], it is impossible to quickly see if anything was stored at all, so the only clear path is to repeat measurements that result in an error [Haha!]. This often results in redundant measurements being actually-recorded, but who would know that at the time of measurement. (These measurements often take about 4 minutes each, so these errors [Haha!] and repeated measurements can consume significant portions of an expensive workday.) 7. (Your main point): Exporting a CSV file of [whatever-the-hell was collected] is possible, as long as I want to send it to Google Drive or some other Clown-based service. The CSV is only a few tiny kilobytes at very most, but it won't let me copy the CSV to my pocket-computer's clipboard, or send it in an email, or save it locally on the pocket computer, or send it with Bluetooth to my laptop. It has to be exported to a Clown-based service, and then it can be read from that Clown-based service by some other device. There are no other options presented, unlike in so many other apps in my pocket computer. 8. Continued: While the maker of this meter device has their own Clown, and this Clown is clearly extent on the Internet, this Clown is completely inaccessible outside of their pocket-computer app. I cannot bypass Step 7 by any official means no matter how deep my desktop computing prowess may be. It is completely shit, and it appears to be the best thing available on the market in this space. (And it isn't even Chinese shit: The company that produces this meter is in Utah.)
GuB-42 2y ago
There are many ways of sending files between phones, none of them good. Bluetooth can work, but it is slow as hell, and Apple doesn't support it. Cloud services are convenient, but you not only you need some signal, but you also uses up your data plan. If you have USB OTG support, you can simply use a thumb drive, like with your PC, but it is cumbersome and you need the hardware. There are some somewhat proprietary systems like QuickShare and AirDrop, which are supposed are great when you have support which is not always the case. Other options include having one phone act as a WiFi AP and host a local HTTP server, there are apps for that (ex: MiXplorer). A bit uncommon, but the advantage is that only one phone needs to do weird stuff, for the other, it is just downloading from a URL. There are also apps like SyncThing based on P2P networks. Generally, phones are pretty terrible at dealing with files. Their OS is designed around apps controlling their data rather than around interchangeable files like traditional desktop OSes. The way they want you to work is not by exchanging .gpx files but instead by using some built-in "share" feature of your hiking app. It may be .gpx under the hood, but they don't want the end user to see a file.
- clan 2y ago
  I agree and get your point. But localsend has worked well for me. Yes, it requires an app but if we could get vendors to bundle that rather than a boatload of bloatware. I know that it would be to optimistic to hope for Google. See https://localsend.org/ https://localsend.org/ Spread the word.
  - ssl-3 2y ago
    Localsend looks neat, but they're absolutely pissing into the wind by saying that it is "Open-source Airdrop" in the title in the Play store. That's a clearcut case of absolutely willful trademark infringement, and it will not go well for the authors when (not if) Apple happens to cast their gaze in that direction.
- Rinzler89 2y ago
  >Bluetooth can work, but it is slow as hell, and Apple doesn't support it. Wait, seriously? iPhones still don't support Bluetooth file transfers? I knew this was the case with the first iPhone but I just accepted that's a limitation from the OS being still an early release of a brand new product with limited functionality, I wouldn't have expect this to be the case after 15 years. Anyway, I'm still baffled we never got a standardized Wi-Fi file transfer protocol, like with Bluetooth but at wi-fi speeds. Oh right, nevermind, Apple wouldn't have supported anyway versus their own proprietary one that only works on Apple devices.
ryandrake 2y ago
I recently had to have a non-technical person send me a very large file, and encountered this. There really is no good universal way to do this, even here in 2024! File is too big for E-mail, ftp is too big a technical hurdle for the guy. Dropbox requires accounts and sharing and all sorts of access shit for him to figure out. I ended up enabling WebDAV on an existing web server I have admin access to, and luckily he's on MacOS which makes it relatively straightforward to write a file to WebDAV. If he were on Windows I have no idea what I'd ask him to do, since I tried for 20 minutes to figure out how to actually connect to a WebDAV folder in read-write mode and Microsoft thwarted me at every turn. It's pretty shocking that we don't have a dead-simple cross-platform "send a file to someone over the Internet" solution that doesn't involve cloud servers and accounts and downloading apps.
- shiroiushi 2y ago
  >File is too big for E-mail, Back in the old days, we would have used PKZIP or RAR to split the file into smaller pieces. >ftp is too big a technical hurdle for the guy Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done. I'm not sure what happened between then and now, but these days people just say "I'm non-technical" and refuse to learn anything that doesn't involve a GUI. FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use: 1. ftp [ip address] 2. type username 3. type password 4. cd dir-to-drop-files 5. put filename 6. quit These days, we'd use sftp anyway, but you could also use scp in a single command line which they could simply copy-and-paste from an email, after you have their temporary account set up.
  - dspillett 2y ago
    > Back in the old days, we would have used PKZIP or RAR to split the file into smaller pieces. Back then there were far fewer non-technical people using email anyway. In my experience people like office admins wouldn't do anything with split archives they would get the local computer person to do it for them (and the same would happen at the receiving end). They were generally aware of zip files, but might get a local tech to compress things for them even if a split archive wasn't needed. Or they would just send a floppy in the post if the file would fit on there but the email limit at one end or both was less than 1440K. On one occasion because no one was free to help otherwise I remember a secretary driving a floppy between campusesses to deliver updated slides for a talk because she couldn't get it pushed through email (I forget if the biggest blocker was at the sending or receiving end). Things changed quite a lot when decent GUI zip tools became common, and again when shell-integrated ones arrived in the Win95 era. Flipping back through time to now, there are two problems that we didn't have back then: 1. Phones don't have particularly good+friendly archivers, and even if one is found security protections might mean said archiver can't access the data it needs from the app that generated it. As well as talking someone through the archiving process you might need to try work out how to open the relevant permissions and describe that to the remote non-technical user too. 2. Often desktop environments are locked down too, and Windows for instance doesn't come out of the box with an archiver, neither CLI nor GUI, that supports multi-volume archives or encryption worth bothering with. > Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done. Some would do that, but I wouldn't say they were the majority by quite a margin in my experience. And not just secretaries: higher paid managers & such too. In fact them more so (as they would drop the task on a secretary, who would then enlist the office kid who knew some tech). > FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use: The issue with that was (still is) that they will need telling each time. It isn't their job to do these technical things so if they don't have an active interest they aren't going to spend time learning it, so they can work out the exact sequence for next time unless it happens often enough that they learn by repetition. It isn't hard, but it isn't natural or familiar to many. It is only natural to you and I because we do that sort of thing regularly (or have done it enough in the past that it has become wired in).
anthk 2y ago
Briar can send files over Bluetooth.
dylan604 2y ago
To me, this seems like a feature the app you're using with the GPX should add to its social settings with a Share With Friend(s) button. Specifically knowing that being in an environment where cell coverage might not be available, it can form adhoc wifi, and push across. Of course, they will want you to allow access to Contacts to know who your friends are. But you've probably already been requested for any of the permissions needed for this feature, because $REASONS
- deleted 2y ago
  [deleted]
philbin 2y ago
[dead]
xgkickt 2y ago
Phones are able to capture MiBs per frame via their cameras, so I wonder if you could make an app that has both playback and recording of data, like displaying an animated QR-like code on one phone and recording it on another.

Varriount 2y ago

Huh, I wonder what the problem was. I semi-regularly send files between my Windows laptop and my Android phone. I do recall never being able to get that functionality working properly with a Mac though.

francescovv 2y ago
That was between two Android phones, with receiving phone being "oppo" or some such, with stock firmware. Receiving phone would see incoming file request, ask user to accept, then error out with "unknown file", and no way to actually save it. I've sent files via bluetooth from lineageos to lineageos, no problem.
- Varriount 2y ago
  I could totally see it being something stupid in how Android manages file associations or something. The default file managers tend to be fairly crippled and only actually show a subset of files present.
  - actionfromafar 2y ago
    Perfect irony would be if the receiving Android attempts to check the incoming file against some kind of Internet service.
- AshamedCaptain 2y ago
  It also possible it just dropped it silently in the Downloads directory. Otherwise ironical that all of this behaves like the 90s PalmOS which could not store a file unless a program would accept it.

nvarsj 2y ago

Pretty easy with iPhone+AirDrop. Just bring your iPhones together - it asks if you want to airdrop something, select file, done.

everfrustrated 2y ago

On Android builtin as Share -> Quick Share/Nearby share Available since Android 6 (c.2015)

sandyarmstrong 2y ago
Have you tried it? It's horribly slow.
- HeyLaughingBoy 2y ago
  I use it all the time. I guess I'm just patient :-)
- ssl-3 2y ago
  I've tried it. I've had it be horribly slow, wickedly fast, and also absolutely fail to work at all. The wickedly fast method seems to involve the two devices forming an ad-hoc WiFi network -- just for themselves. 802.11ac/ax is pretty darned fast when there's no competition, on a network with exactly two nodes, and when those two nodes are separated by only a couple of feet. IIRC, this is not the default mode of operation.

ssl-3 2y ago

Sometimes, I work with bi-directional amplifiers and distributed antenna systems that are intended to improve cellular coverage inside of a building where there may be little or none of that. I have a fairly expensive meter at my disposal to use for planning things like this, which analyzes different cellular carriers by frequency, and can output (messy, and with unescaped commas for notes, but eventually-fucking-usable) CSV files of the results -- with GPS coordinates of the measurement location. This sounds amazing for a person like me in this line of work. But it is not amazing for a person like me in this line of work. (As a preface for the rest of this, remember: This meter is a tool that is meant to be used in areas of limited or zero cellular coverage -- places where outside RF is problematic for whatever reason.) 1. The meter has a Bluetooth interface that connects to an app on a pocket computer. (This part works fine, usually, except the app often doesn't background properly and silently dies if the user uses their pocket computer to do some other task, which might be fine if the problem was ever reported. [Haha!]) 2. The meter expects the pocket computer to have an Internet connection, so it can use that to upload its findings to The Clown. (This part often cannot work, because the whole fucking reason any of this is happening is because cellular coverage is shit inside of a random building.) 3. The meter expects that the pocket computer will provide GPS coordinates, even though it is intended to be able to be used indoors -- without network connectivity, or perhaps even in a Faraday cage. And while modern pocket computers are very good at providing some location data by various means as long as there is internet connectivity or GPS-esque data, all of them fail at this when there is neither Internet nor GPS available. It produces an error [Haha!] when there is no location information available. 4. It does not provide useful errors. It provides errors, but they aren't specific at all and do not promote productive troubleshooting or workflow. ("Oh, there was a problem with your measurement! [Haha!]" is the singular error.) 5. Sometimes, it will even produce an error [Haha!] but record the measurement anyway -- and without recording the error. 6. It stores nothing locally. When an error happens [Haha! Good luck!], it is impossible to quickly see if anything was stored at all, so the only clear path is to repeat measurements that result in an error [Haha!]. This often results in redundant measurements being actually-recorded, but who would know that at the time of measurement. (These measurements often take about 4 minutes each, so these errors [Haha!] and repeated measurements can consume significant portions of an expensive workday.) 7. (Your main point): Exporting a CSV file of [whatever-the-hell was collected] is possible, as long as I want to send it to Google Drive or some other Clown-based service. The CSV is only a few tiny kilobytes at very most, but it won't let me copy the CSV to my pocket-computer's clipboard, or send it in an email, or save it locally on the pocket computer, or send it with Bluetooth to my laptop. It has to be exported to a Clown-based service, and then it can be read from that Clown-based service by some other device. There are no other options presented, unlike in so many other apps in my pocket computer. 8. Continued: While the maker of this meter device has their own Clown, and this Clown is clearly extent on the Internet, this Clown is completely inaccessible outside of their pocket-computer app. I cannot bypass Step 7 by any official means no matter how deep my desktop computing prowess may be. It is completely shit, and it appears to be the best thing available on the market in this space. (And it isn't even Chinese shit: The company that produces this meter is in Utah.)

GuB-42 2y ago

There are many ways of sending files between phones, none of them good. Bluetooth can work, but it is slow as hell, and Apple doesn't support it. Cloud services are convenient, but you not only you need some signal, but you also uses up your data plan. If you have USB OTG support, you can simply use a thumb drive, like with your PC, but it is cumbersome and you need the hardware. There are some somewhat proprietary systems like QuickShare and AirDrop, which are supposed are great when you have support which is not always the case. Other options include having one phone act as a WiFi AP and host a local HTTP server, there are apps for that (ex: MiXplorer). A bit uncommon, but the advantage is that only one phone needs to do weird stuff, for the other, it is just downloading from a URL. There are also apps like SyncThing based on P2P networks. Generally, phones are pretty terrible at dealing with files. Their OS is designed around apps controlling their data rather than around interchangeable files like traditional desktop OSes. The way they want you to work is not by exchanging .gpx files but instead by using some built-in "share" feature of your hiking app. It may be .gpx under the hood, but they don't want the end user to see a file.

clan 2y ago
I agree and get your point. But localsend has worked well for me. Yes, it requires an app but if we could get vendors to bundle that rather than a boatload of bloatware. I know that it would be to optimistic to hope for Google. See https://localsend.org/ https://localsend.org/ Spread the word.
- ssl-3 2y ago
  Localsend looks neat, but they're absolutely pissing into the wind by saying that it is "Open-source Airdrop" in the title in the Play store. That's a clearcut case of absolutely willful trademark infringement, and it will not go well for the authors when (not if) Apple happens to cast their gaze in that direction.
Rinzler89 2y ago
>Bluetooth can work, but it is slow as hell, and Apple doesn't support it. Wait, seriously? iPhones still don't support Bluetooth file transfers? I knew this was the case with the first iPhone but I just accepted that's a limitation from the OS being still an early release of a brand new product with limited functionality, I wouldn't have expect this to be the case after 15 years. Anyway, I'm still baffled we never got a standardized Wi-Fi file transfer protocol, like with Bluetooth but at wi-fi speeds. Oh right, nevermind, Apple wouldn't have supported anyway versus their own proprietary one that only works on Apple devices.

ryandrake 2y ago

I recently had to have a non-technical person send me a very large file, and encountered this. There really is no good universal way to do this, even here in 2024! File is too big for E-mail, ftp is too big a technical hurdle for the guy. Dropbox requires accounts and sharing and all sorts of access shit for him to figure out. I ended up enabling WebDAV on an existing web server I have admin access to, and luckily he's on MacOS which makes it relatively straightforward to write a file to WebDAV. If he were on Windows I have no idea what I'd ask him to do, since I tried for 20 minutes to figure out how to actually connect to a WebDAV folder in read-write mode and Microsoft thwarted me at every turn. It's pretty shocking that we don't have a dead-simple cross-platform "send a file to someone over the Internet" solution that doesn't involve cloud servers and accounts and downloading apps.

shiroiushi 2y ago
>File is too big for E-mail, Back in the old days, we would have used PKZIP or RAR to split the file into smaller pieces. >ftp is too big a technical hurdle for the guy Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done. I'm not sure what happened between then and now, but these days people just say "I'm non-technical" and refuse to learn anything that doesn't involve a GUI. FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use: 1. ftp [ip address] 2. type username 3. type password 4. cd dir-to-drop-files 5. put filename 6. quit These days, we'd use sftp anyway, but you could also use scp in a single command line which they could simply copy-and-paste from an email, after you have their temporary account set up.
- dspillett 2y ago
  > Back in the old days, we would have used PKZIP or RAR to split the file into smaller pieces. Back then there were far fewer non-technical people using email anyway. In my experience people like office admins wouldn't do anything with split archives they would get the local computer person to do it for them (and the same would happen at the receiving end). They were generally aware of zip files, but might get a local tech to compress things for them even if a split archive wasn't needed. Or they would just send a floppy in the post if the file would fit on there but the email limit at one end or both was less than 1440K. On one occasion because no one was free to help otherwise I remember a secretary driving a floppy between campusesses to deliver updated slides for a talk because she couldn't get it pushed through email (I forget if the biggest blocker was at the sending or receiving end). Things changed quite a lot when decent GUI zip tools became common, and again when shell-integrated ones arrived in the Win95 era. Flipping back through time to now, there are two problems that we didn't have back then: 1. Phones don't have particularly good+friendly archivers, and even if one is found security protections might mean said archiver can't access the data it needs from the app that generated it. As well as talking someone through the archiving process you might need to try work out how to open the relevant permissions and describe that to the remote non-technical user too. 2. Often desktop environments are locked down too, and Windows for instance doesn't come out of the box with an archiver, neither CLI nor GUI, that supports multi-volume archives or encryption worth bothering with. > Back in the old days, even a secretary could figure out how to use the MS-DOS command line well enough to get her job done. Some would do that, but I wouldn't say they were the majority by quite a margin in my experience. And not just secretaries: higher paid managers & such too. In fact them more so (as they would drop the task on a secretary, who would then enlist the office kid who knew some tech). > FTP isn't hard, it's just a few commands, and it's much easier to tell someone how to send FTP than to use any GUI, since you can type out the exact commands to use: The issue with that was (still is) that they will need telling each time. It isn't their job to do these technical things so if they don't have an active interest they aren't going to spend time learning it, so they can work out the exact sequence for next time unless it happens often enough that they learn by repetition. It isn't hard, but it isn't natural or familiar to many. It is only natural to you and I because we do that sort of thing regularly (or have done it enough in the past that it has become wired in).

anthk 2y ago

Briar can send files over Bluetooth.

dylan604 2y ago

To me, this seems like a feature the app you're using with the GPX should add to its social settings with a Share With Friend(s) button. Specifically knowing that being in an environment where cell coverage might not be available, it can form adhoc wifi, and push across. Of course, they will want you to allow access to Contacts to know who your friends are. But you've probably already been requested for any of the permissions needed for this feature, because $REASONS

deleted 2y ago
[deleted]

philbin 2y ago

[dead]

xgkickt 2y ago

Phones are able to capture MiBs per frame via their cameras, so I wonder if you could make an app that has both playback and recording of data, like displaying an animated QR-like code on one phone and recording it on another.