Syncthing Android App Discontinued

Put a lot of scary warnings around it then. It's for the user to decide if they want to take the risk or not. Google took something that solved real problems better than any alternative could, did so for many years, and destroyed it for no real reason other than to further tighten control they have of the supposedly "open" platform.

They did, the upstading app developers like this one just forced people to give them full access to all data in the app (or the app wouldn't run) and ended up not implementing scoped storage - something HNers outright demanded several times and exposed as a good upside of iOS.

So stick had to come out. The full filesystem access is now reserved for apps that manage full filesystem (e.g. file explorers) and that's it. Scoped storage APIs were introduced in 2013, 11 years ago and Play started enforcing them in 2020, so the experiment with scary warnings was running for 7 years and developers refused to give up on that sweet full private file access.

Granted, SAF is quite a shitty API.

I mean, syncthing is exactly the kind of app I would expect to have full filesystem access.

Why? I want it to have access to the folders I want it to sync, not everything on my device.

Seems like a perfect fit for SAF.

In a perfect world, what Syncthing does would be handled at the OS level and all OSes would seamlessly interoperate. In the real world the OS vendors are hostile to interoperability so the only way to get that is with a third-party tool that has OS-level access.

It's my phone. It's my data. It's my choice to install the app. It's my choice to grant the permissions to all files. Because guess what, I'm using the app to sync all my files.

I really can't agree with Google in this particular case.

And yet you'll blame Android when some app steals a lot of data just like it always happens on this site.

There are Android APIs to let syncthing integrate as cloud provider itself and the author didn't use those either.

I couldn't agree more. Given how much frigging hoops I had to jump through to get my Obsidian over syncthing setup to sync with my company iPhone - I nearly gave up.

I grew up when computers didn't babysit me and tried to act like the good old GDR, knowing every thing better than their citicens.

Nowadays, I feel more and more hindered by computers, not enabled. Computers used to be a production device (I could create things with them).

Phones are not a computer - phones are a just "consume like we want you to" device.

The problem is, I want my phone to be a creation device. A device that allows me to create content, text, to do lists, shopping lists, ideas and store them. And(!) sync them using the tools I decide to use. And not force me to use tools I friggin hate, because they just don't get the job done.

No. Not in my world. Because I actually want to be able to backup my phone - not only demarcated parts of it.

I want to be able to get all data from my phone - regardless of what it is and what app put it there.

If I decide to only sync specific folders. So be it. But I want to be able to sync "/"

It's an open-source program, it shouldn't be held to the same standards as a closed-source program that just shuttles all of your data to someone else's computer.

The risk here isn't misuse of the data, it's that some exploit is found in the code, and the additional protection of limiting its filesystem access is marginal (but nice to have).

How did you get iPhone Syncthing + Obsidian working? I was under the impression that it was basically impossible to share Möbius Sync's directory with Obsidian.

That's why you can install through F-Droid right?

> Google took something that solved real problems better than any alternative could, did so for many years, and destroyed it for no real reason other than to further tighten control they have of the supposedly "open" platform.

Technically, the guy who inherited Syncthing Android maintenance destroyed it because he didn't want to use the file permission APIs.

Which, of course, is a reasonable decision for a maintainer to make when they're working with limited resources. But I have to say in this case I find some of the maintainer's behavior to be a bit surprising for a project as mature as Syncthing.

> for no real reason other than to further tighten control they have of the supposedly "open" platform

I think you're overlooking the obvious motivation of "maintain a lock on a substantial profit stream".

Have you considered that it's a plural "you" that you're choosing to pit yourself against, with different people each weighing different complaints?

Almost by definition, the people who argue strongly for free use of their hardware and software are almost never the same people who argue strongly for safety and security restrictions. You seem to be frustrated by a contradiction or inconsistency that doesn't exist.

It's true that Google can't win the hearts of both sides, but they surely know that -- you don't need to get so personally frustrated on their behalf. It's just a company with a product in a market, and the market is never going to be uniform.

Or maybe this, plus Panic removing GDrive support from Transmit, plus iA dropping Android support from Writer because of it, point to a common perception that Google's API for doing things "the right way" suck to the point of unusability. If iA and Panic and Syncthing -- all who've supported Android for many years -- can't manage to make it work, then I suspect it's broken.

Google use to allow just any app to access the whole drive. That's probably too permissive. Now they've obviously swung too far the other direction, where even well intended, experienced devs are unable to work within Google's new constraints.

There is a new app Synctrain which does this.

I gave up. My phone now is just a communication and utility device, and thus I don’t feel the urge to upgrade until it can’t do those tasks. I went back to computers (and Linux) to be able to just use them as a computer.

The java.io.File API isn't removed from Android, nor inaccessible. You can absolutely still use it. Google Play has chosen to not accept it on their store unless you justify it (to their non working bots). In this case, the dev chooses to just drop the entire app because maintaining it just for Fdroid feels pointless.

There's very few permissions on android that are system/privileged/preinstalled.

I want it to be able to browse to another app's private folder to sync the data of that app to my computer. If browsing to there it's not the job of syncthing then I need a file manager with those permissions.

For 3 years now I can't open my Downloads or Pictures folder without root, because their shitty API is unbelievely bad that it would take around 30 minutes to open a folder with that many files.

In reality, Syncthing is also pretty good at destroying battery life unless you go above and beyond to configure it in a way that then hampers Syncthing's ability to provide seamless file continuity between devices. I know that there will be disagreement here, but in my own opinion OS vendors are correct in being hostile to these apps under current circumstances. They could provide better ways to have third parties implement it and provide cross platform support for their platform solutions, but I've had Syncthing be the #1 cause of battery life drain on multiple devices and platforms before and it's honestly just not worth fighting with it. To get it under control relegates it to being not much better than rsync.

I guess I'm a bit at a loss about why these app developers feel they need access to things like medical records stored on the work phone of everybody at your doctor's office.

If they do need access to literally everything on the device, then it seems reasonable that they have to pass some minimum security bar. After all, several of the apps whose data they want access to are used to secure things like private medical records, classified information, etc.

At some point, the encrypted data has to be mounted as plaintext so apps can work with it. It seems reasonable to ask for some kind of permission system so that apps have to declare they need to read these files and so users can make a decision about whether to allow that access. But these developers are refusing to even ask for that permission.

We both know that first bit is a strawman, so we can move past it.

From the description of the people who wrote these apps, there are 2 basic APIs at play:

1. Get access to the entire drive.

2. Ask for permission to individual files.

I would have assumed there was a middle ground like asking for permission to a specific folder's contents, yet those same devs insist that's not the case. iA Writer users want to edit everything inside a folder. Syncthing users want to sync an entire folder. Transmit users want to select upload/download to/from an entire folder. If Google made those APIs available then we wouldn't be having this conversation.

So Google drive doesn’t have full filesystem access anymore?

I think it's important to draw a distinction between OS providers and app store providers here. The fact that they're the same entity in most cases is or should be largely irrelevant.

OS vendors shouldn't make it impossible to create apps that have unlimited access to the filesystem or that suck battery in the background. There are reasons users might want to run apps that do either or both - a file indexer, for example. All the OS should do is ask the user if the app has permission to do those things.

An app store provider on the other hand might reasonably have many criteria for inclusion, such as F-Droid only allowing FOSS. This only becomes problematic when the app store in question is effectively a monopoly.

> We both know that first bit is a strawman, so we can move past it.

Privacy and security are literally the reasons for these APIs. I don't see how you could possibly call that a strawman.

> I would have assumed there was a middle ground like asking for permission to a specific folder's contents,

Isn't that what OPEN_DOCUMENT_TREE does? https://developer.android.com/reference/android/content/Inte...

> Seems like a perfect fit for SAF.

Except SAF is slow as hell, working on multiple files means separate calls for every little thing like file size via java API. Means everything going to be VERY slow and drain battery a lot. I've seen test from 2019 where directory listing operation is 25-50 times slower in SAF

https://issuetracker.google.com/issues/130261278

Same. I wish there were an alternative (a practical pocket computer), but there really isn't. So I too gave up on fighting my phone, and have also completely stopped doing mobile development. I now treat my phone essentially as an untrusted, prepackaged walled garden with limited utility. :-/

You don't have root. Google does.

I'm not saying that's a good thing, but it's not exactly a secret when you bought it.

You're right; my bad. What you said was:

> I guess I'm a bit at a loss about why these app developers feel they need access to things like medical records stored on the work phone of everybody at your doctor's office.

...which isn't a strawman. It's begging the question by presuming that authors actually feel such a need. I'm fairly certain the devs involved do not want or care about accessing medical records.

As to OPEN_DOCUMENT_TREE, to my naive eyes that's what it looks like to me, too. That said, I'm confident that the devs we've discussed here, particularly the ones who sell the related apps for their livelihood, are clever enough to read the docs and that they've ruled it out for some reason. I certainly don't think the Syncthing team is too incompetent to use a documented method if it magically did the right thing.

> . It's begging the question by presuming that authors actually feel such a need. I'm fairly certain the devs involved do not want or care about accessing medical records.

iA -- one of the cases you mention -- balked at needing a standardized security assessment to access the full Google Drive.

> In order to get our users full access to their Google Drive on their devices, we now needed to pass a yearly CASA (Cloud Application Security Assessment) audit.

https://ia.net/topics/our-android-app-is-frozen-in-carbonite

Googe Drive as part of Workspace is HIPAA compliant (https://support.google.com/a/answer/3407054?hl=en), meaning medical offices can and do host medical records on Drive. It's not mentioned in the article why iA needs access to all files on a HIPAA compliant service.

Workspace is also (at least partially) FedRAMP compliant (https://support.google.com/a/answer/13190816?hl=en). So similar questions arise as to whether iA needs to access federal data.

> I wish there were an alternative (a practical pocket computer), but there really isn't.

There really is: https://puri.sm/products/librem-5.

And it's my daily driver.

Got it working myself. I set up a share inside of Mobius Sync that reaches into the Obsidian folder. (note the entire thing, just one vault). I think there was a popup saying it was unsupported but I haven't had any problems yet.

That’s still not your product though. You only bought a licence.

Flash your favorite open firmware, enjoy and let regular users who cannot do that avoid permission extortion. The world has needs and issues, it is not spinning around your skillset.

You mean google drive subscriptions? Are such revenues even "substantial"? AFAIK google makes the overwhelming majority of its revenue from ads.

That's exactly what OPEN_DOCUMENT_TREE does. The typical workflow involves presenting a directory picker activity to the user and asking them to pick a dir (the app can then retroactively ask the OS to persist these permissions across restarts.)

However: - You can't pick the root of a storage volume, only its subdirectories. This is presumably for your own good. - The application is still forced to use the SAF APIs, which are slow (each call requires an IPC) and overcomplicated. For working with multiple files, directory listings, etc, naive use of SAF can be a couple orders of magnitude slower than standard File APIs. This can be sped up, but it's never going to be anywhere close to native speed.

I can imagine devs throwing a fit about that, then. They’re the ones who’ll get bad reviews even if it’s out of their control.

I use Sailfish OS as my daily driver since 2013.

https://en.m.wikipedia.org/wiki/Sailfish_OS

Thanks for the info. I haven't looked at this in a while. I'll take another look!

Appreciate the feedback. For some reason I feel like I dismissed this as an option at one point, but that was long ago. I'll take another look!

I use syncthing to back up my entire Android phone.

At least the parts it can access, anyway: /storage/emulated/0