The important thing to remember is that running any program on your device possibly exposes any data it can access. You might be pointing it to only /path/ciphertext, but if you don’t isolate the process from the rest of the system, it may just as well access /path/plaintext on its own. If running software with your regular user access privileges, you always need to trust it that much. The only protection for untrusted software is a strong sandbox enforced by the OS.
6 Likes
The part you quoted is for Syncthing-Fork, which is the Android app. Android already has the security/sandbox you are talking about. If you use GrapheneOS you can further use Storage-Scopes. This is the best we have got as far as I’m aware of and it’s pretty darn good so there’s little concern there.
Desktop OS however is a different story esp Linux - it’s the worst of the big 3 (MacOS, Windows, Linux) and ordinarily (or even with considerable effort) it’s a security nightmare. Other 2 are more secure but ofc a privacy nightmare. If it bothers someone they can use the sandboxing via VM compartmentalisation of QubesOS which is as good as it gets for Linux (well Xen) as of today that I’m aware of. Or much more easily but lower security would be running desktop Syncthing in a docker container and mounting the encrypted dir as a volume - this is actually what I use on Arch (an otherwise security nightmare but “fun” 
)
Anyway, trusting an offline app (droidfs/gocryptfs) is slightly easier for me and results are more easily inspectable (ie the encrypted folder only contains ciphertext/junk) than an online app going rouge.
1 Like
@monozygote @acolomb If you want to continue your discussion, please, do so in a new thread. I want to be notified of new posts about the topic of this thread only. Thanks.
8 Likes
fair, but also I think (possibly incorrectly) this thread is already past its usefulness in that case:
Does anyone know why syncthing-fork is no longer available on Github? General
It is available in Github now, there was a blackout briefly, presumably due to handover and is back in development now with a different maintainer. Due to this thread being sort of highly ranked in search engines folks (like me) will keep coming in with related-but-not-entirely kinda posts
Probably lock it?
@monozygote you joined two days ago and you’re asking for this thread to be locked?
This is a very useful thread for people concerned about the current fork status and like you said is the top search result
4 Likes
Yeah sorry my bad didn’t mean it that way. Have been following for a long time, only joined recently to share something I thought could be useful (or discussion-worthy or whatever)
1 Like
Hello,
Could you so kindly put a note at the top of the archived repo, or edit the description to say where the development has moved? Potentially adding the reason as you stated.
It’s to the benefit to add reasons when a repo is archived so that users of said repo know where to go.
Thanks.
2 Likes
There is an open invitation to bring the repo within the organisation.
researchxxl Have you seen or publicly responded to this invite? Would go a long way in ensuring what happened with Catfriend doesn’t happen again.
1 Like
am I late to the party? I could propose new M3-based designs and, on pastime, implement them with Compose. just need to figure my way out of these effin’ outages, damned Russia…
it kinda hurts to see many great open-source apps adopt a design language that makes them cohesive with each other. core UX will stay largely the same, it’s made well. my only concern is looks.
Hey! I feel the same. And I’m trying to do exactly that. Feel free to check it out in the repo. The dialog box for showing device id qr code is done already and right now I’m upgrading the settings.
Can you explain that in the README?
This repo is merging into https://github.com/nel0x/syncthing-android.
and https://github.com/nel0x/syncthing-android says
I will continue the full development and maintenance here going forward
but it is archived… This is all very confusing.
Some comments point to GitHub - researchxxl/syncthing-android: Syncthing-Fork - A Syncthing Wrapper for Android. as a successor project, but the issue about that handover has been deleted…
https://github.com/researchxxl/syncthing-android/issues/16
What is going on??
The whole situation can easily be confusing, especially if you read the whole topic here, as things were changing quite dynamically. From my understanding, the final conclusion is that everyone eventually agreed to work together on a single Android application under https://github.com/researchxxl/syncthing-android. Alternatively, there is an experimental Android version of https://martchus.github.io/syncthingtray, or you can also run Syncthing from a command line using Termux.
3 Likes
SUMMARY
I’ve spent hours going over all 233 comments, discussions in other forums as well as Github.
The highlights of this situation are:
Catfriend1confirmed his retirement from Syncthing Android development and ownership transfer toresearchxxl(#165).researchxxlmade a public announcement to clear up the confusion as well as his goals and intentions going forward (#195).- The original repository got pruned and future development will be carried out in: researchxxl/syncthing-android with help of
nel0x(person responsible for Playstore Releases since Syncthing-Fork). - F-Droid & Syncthing developers have confirmed there’s no indication of malice in the new repository for now. Previous commits have not been altered (#141).
- Syncthing-Fork builds are still fully reproducible to prevent supply chain attack (#65). For greater safety you can opt to use F-Droid builds as there’s more time between version bumps from upstream code releases to spot any wrongdoing.
- The transition wasn’t transparent at first which caused a lot of confusion and mistrust.
Alternative FOSS projects:
-
SyncthingTray (Martchus/syncthingtray):
Cross-platform Syncthing Wrapper with Experimental Android support. The developer has excellent track record and is very active.
-
BasicSync (chenxiaolong/BasicSync):
Minimal wrapper for Syncthing on Android. Unlike Syncthing-Fork, it does not use Android’s Storage Access Framework to avoid performance degradation. The intention behind this project can be found here. This one needs more vetting from the community to determinate if the developer is trustworthy.
PLEASE STOP COMMENTING WITHOUT CONTRIBUTING NEW FACTS
Every new comment notifies hundreds of people. Nothing new has been said for past 200+ comments
18 Likes
Maybe just one thing is missing from the summary IMO: #222 Does anyone know why syncthing-fork is no longer available on Github? - #222 by calmh
“There is an open invitation to bring the repo within the organisation.”
8 Likes
FWIW, this developer, chenxialong, has quite a strong reputation in the Android community. He’s had pull requests merged into GrapheneOS (Add high EMF (PWM) mode setting for Pixel 10 series by chenxiaolong · Pull Request #390 · GrapheneOS/platform_packages_apps_Settings · GitHub), which has a very high bar for quality, and he’s active on the GOS forums as well.
I’m still using the original app from Dec 2025, but this is probably the alternative I’ll upgrade to when it becomes necessary/I get around to it.
4 Likes
I had reached the same conclusion for myself: that dev seems to have a good history on github, the contributing to GrapheneOS (which I’m also using myself) is for me also a very good sign.
Can’t really tell if ‘normal’ syncthing-android always uses the Storage Access Framework, but if it does, then this version might actually be speedier. Will give it a go hopefully soon regardless!
1 Like
Especially if you’re using GrapheneOS, you can apply Storage Scopes, which gets you the same level of security as SAF but without the performance hit.
1 Like
Can’t really tell if ‘normal’ syncthing-android always uses the Storage Access Framework, but if it does, then this version might actually be speedier. Will give it a go hopefully soon regardless!
(Hi! I’m the author of BasicSync)
None of the syncthing Android implementations use the Storage Access Framework for file access. Some apps use the SAF folder picker, but internally are still just using local paths. Unfortunately, SAF is pretty poorly designed for what Syncthing needs. I’ve listed a few technical reasons in the README for BasicSync.
Performance wise, every syncthing Android app should be about the same.
From a user’s point of view, there are two main differences in how BasicSync runs syncthing compared to apps based on the original syncthing-android:
- Syncthing is embedded as a library in the main process, rather than running the
syncthingcommand as a child process. For folks on Android 12+ who do not disable child process restrictions in Android’s dev settings, this design makes it so syncthing will never be killed due to high CPU usage, like when it is hashing files.- (But for folks with rooted devices, this makes it impossible to run syncthing as root)
- By default, when the app does not permit syncthing to run (eg. low battery level or metered network), syncing is paused without shutting down syncthing entirely. When it’s allowed to run again, it resumes without having to rescan every shared folder. This usually doesn’t matter unless you have huge shared folders.
EDIT: Also, there are significant differences in customizability and UI. BasicSync will never be as flexible as other apps and configuring things is done through syncthing’s web interface.
14 Likes
Thank you for joining the discussion, and creating another option for us!
This might actually be a(nother) big plus for me, as I find scanning my synced whatsapp folder of 16.8k files can take quite a while.
3 Likes
I’m a huge fan of storage scopes (and contact scopes maybe even more, whilst were on the topic).
1 Like