Does anyone know why syncthing-fork is no longer available on Github?

General
218

This doesn’t sound normal unless your device runs out of memory completely or the OS uses some kind of “battery optimisation” techniques that kill background apps (see https://dontkillmyapp.com :sweat_smile:). I’ve been using Syncthing via Termux on multiple Google Pixel devices running GrapheneOS for a long time, and I don’t remember it ever getting killed.

2 Likes
220

@nel0x Are you the next developer which got lost?

@calmh @AudriusButkevicius Do you plan to take Syncthing for Android into your repo?

1 Like
221

@Labtitan because for now we have agreed on continuing development on @researchxxl’s Repository (and I don’t want mine to be a ‘competing’ repo) and @bege, yes they don’t have anything against it, hopefully it will be merged into the Syncthing Org by researchxxl sometimes in 2026.

11 Likes
222

There is an open invitation to bring the repo within the organisation.

9 Likes
223

@tomasz86 You’re correct, battery optimisation was killing Termux. Changing that to allow unrestricted background use resolved that. Over several hours Termux has now used 1% battery. I’ll continue to monitor battery consumption over 24 hours of Syncthing connection. Thanks for the insight.

224

I feel a bit left alone with a repo owner with very specific not user oriented ideas like removing root access. Currently I only can use your “competing” release.

225

Hi @nel0x , could you help me clarify this one - Syncthing Fork on Playstore will continue to maintain with build from @researchxxl ? Or Syncthing Fork on Playstore will be shutdown forever ?

Thank you

2 Likes
226

could you help me clarify this one - Syncthing Fork on Playstore will continue to maintain with build from @researchxxl

Yes, thats the plan. However it gets build in the future it will not disappear on the Playstore.

5 Likes
227

Thanks for your effort @nel0x , I think it will be the best if @researchxxl include your playstore link to @researchxxl’s github repo like recognize and clarification for you.

I’ll continue to use your build on Playstore, it also help everyone want to use app on Playstore and don’t need reinstall other app on Playstore as well. Btw if you need support from Android development, please ping me I’m Android dev like you :folded_hands:

1 Like
228

hey @nel0x i am happy we now aim to work together to get the best for the community and users of the app :)) i very welcome your contributions - meanwhilst there are two or three new contributors on the repo and with a handful of people imo we have great options to do coding supporting and publishing together with each contributors strenghts in different places

i am currently busy testing.. uh.. researching different variants of translation config to reinstate the translation of the app via a fixed branch and freq pulls

just let me know if you need anything to open the way for our working together =)

if you require i can also add bundlerelease to the release process - just saw if comparing our repos that this was the main diff between them you give users aab and me giving out apk artifacts

please choose freely and alter any time you see fit: what is your main aim to contribute?? am i guess right you focus on publishing the google play artifacts?? would you also have interest in coding and support aid??

229

i am sorry for that!! did not intend to leave you alone but the root feature really was unmaintained for years and i do not have magic powers or four research hands to do it.. maybe give @nel0x a little bit to land and settle in the new situation and we could politely and calmly ask them if there is interest to maintain at least the aged code for the google play release branch - if there will be any - so the minority of root users still has a way to load a build including the feature?? sure.. they would need to test from time to time but the code removed did not look huge nor complicate so feasible if they wanna take the time

230

I mean if we put in the work to maintain it would there be any reason to not include it in the ‘main’ flavour - thus not diverge in a GPlay-specific capability? Generally I can take this feature under my umbrella, but I don’t use a rooted device myself too, so this feature would be on a ‘best effort’ basis …

3 Likes
231

I was previously working with @Catfriend1 on the translation setup. We can integrate it with the existing project on Hosted Weblate again, which has the advantage of easier sharing between different Syncthing components.

However if the repository is going to move into the syncthing organization, I’d like to wait for that so we can make a clean setup and not move around willy nilly.

4 Likes
232

Can we continue this issue in the respective github issue? Full Device Storage Access · Issue #60 · researchxxl/syncthing-android · GitHub

I am ready to test root access.

233

Just removing it was not a good idea. Searching for help - now found with @nel0x - and leaving it for now is the better idea IMO.

234

The researchxxl repo now states in the release notes to “Please pay attention to the package ID while upgrading” but it doesn’t say what to do or how to determine which to use. Obtainium sees both the syncthingandroid_release and syncthingfork_release for v2.0.13.0, but which do we choose?

235

Hey @researchxxl, I don’t think we shouldn’t create seperate package name it will be fragmentation for syncthing …

I’m happy when you’re inviting @nel0x to join project for releasing on Playstore but …. please make it official build in syncthing project instead of only a branch.

2 Likes
236

I’m a pretty basic user so i don’t understand the technicalities, but a few months back i remember there was a change in the app id where Obtainmium would throw a warning about the app id not matching and could not update it -iirc the change was related to the transition from v1 to v2 and preventing the app conflicting with something.

You had to go on Github and follow Cat’s instructions on migrating your config and pick one based off of your preference, if you’re like me you probably went with the syncthing-fork id.

237

I was inadvertently left behind on catfriend’s 1.x (I don’t auto-update, and v1 was pulled from fdroid), and have been silently following this the last month or so.

I’m genuinely thinking to leave syncthing-fork in favor of termux or syncthingtray for the near term (I’m glad to see things seeming amicable, but wow has there been a lot of whiplash :distorted_face: ), but I am curious–with catfriend’s repos gone, do the v1→v2 migration instructions still exist anywhere? Or were they lost when catfriend’s v1 repository was deleted?

1 Like
238

I was concerned about this much before this “controversy” unfolded. I was only casually looking for solutions back then but now I’m seriously/actually doing it.

Basically don’t trust syncthing-fork (or even syncthing if you want but I was mostly concerned about the forks/3rd-party stuff) and only share encrypted stuff - so even if there’s a leak (due to malice/incompetence/…) you are better protected (depending on your threat model ofc).

Setup:

  • Linux: Use gocryptfs to initialise/point to an encrypted dir (/path/ciphtertext) and fuse mount it to plaintext dir (/path/plaintext). Point syncthing to /path/ciphtertext
  • MacOS: use gocryptfs again - use macFUSE or whatever it’s called now, or use lima to run a linux VM and share ciphertext and plaintext dirs between host/guest.
  • Android: Use DroidFS - in its settings allow it to create the document provider mounts for plaintext that you can now see via your system-picker/file-picker.

Use syncthing to only sync the ciphertext dir. Since this is not a block-device encryption and per file encryption only the diff gets sync-d, just like it would with regular files. Now even if syncthing-fork or whatever goes rogue, it only touches encrypted stuff so it’s not that bad.

I use GrapheneOS (evident from the link above) so I additionally storage-scope it to just that root dir which contains encrypted files/dirs. Working OK so far.

4 Likes