We should probably call it Syncthing-Spork for two reasons:
When choosing between Syncthing-Fork and Syncthing-Spork, new users will pause and wonder why it exists, which we can reference this thread so they understand the full story. Engagement achieved; also, someone will ask about this anyway, and proactively showing the origin story would be a good solution.
Naming Pipeline: If you, @nel0x, mysteriously disappear for some reason, we won’t run out of naming ideas going forward.
I reached out to the owners of F-Droid to ask them to roll back to the previous trusted version and freeze the account key until everything is settled.
They will not take any action at the moment since nothing malicious has been released so far. They asked to be kept in the loop once there is an update to share.
If something fishy gets released, please report it.
I have also reported the GitHub repository as this whole charade now looks like a supply-chain attack.
@syncedbits There are no missing features, the GPlay release is fully on par with the GitHub/F-Droid versions. As for which to use: Obtainium is a very valid option (and great for bypassing Google), but we shouldn’t have any illusions, >90% of users will stay on Play for the sake of convenience. Use whatever fits you best …
@d98b @DireMunchkin Good catch with the ID! Migrating the 100k+ users on the Play Store should definitely be avoided. For now continueing with com.github.catfriend1.syncthingandroid (already used for GPlay) would be the least burdensome option and for most the ID is mostly a cosmetic internal detail anyway …
As for the naming I appreciate the humor d98b but going back to a simple, professional display name feels like the best way to rebuild project confidence. Unlike the hardcoded AppID, that kind of “soft-branding” is flexible and can always be changed later on or reused by others if required.
General Note: For technical details we should maybe slowly leave this 148-reply topic behind and move to specific topics and Issues/PRs on the Repo itself.
@jan-kaufmann @aTosser Honestly that seems like a reasonable response from F-Droid for now. I mean it’s good that they’re now keeping an eye on it but we should be carefull reporting or flagging reserachxxls repository “preemptively” without specific malice. I can simply move forward by spinning up a seperate F-Droid Listing.
@nel0x, respectfully no, it’s not preemptive. The facts are clear, a project with a very large community changed hands with absolutely no transparency and apparent dubious behavior. It’s pretty damning that researchxxl does not give anything to vindicate themselves and clearly has no desire to.
Not only that but to instead immediately call your trustworthiness into question is tu quoque.
The wait an see approach risks many users.
If a new f-droid listing is the way forward then once everything is set up something needs to be done about the existing one. Not everyone is reading messages in this forum and aware of the ownership change.
Anyone can create a new fork of an archived repo - that’s what open source is about. But they don’t silently inherit the full user base of the original. As it stands today, all existing users will continue to pull from researchxxl without noticing any difference.
It would be fair if Catfriend’s work would be treated as any archived repo. Anyone can fork it and if users want updates they can choose which f-droid listing they want to use in the future. At some point the old one from Catfriend should be closed if this mess cannot be thoroughly explained.
@nel0x the Google Play Store is on 2.0.9.1 and on f-droid the latest Catfriend release was 2.0.11.2.
I know because I had issues with the play Store version that have been fixed in 2.0.11 that’s when I stumbled into this discussion here.
Is it fine to stay on Play store release for now? Is there some reason it hasn’t been updated to the latest catfriend’s release before the takeover/transition?
For someone coming in new to all of this it’s quite confusing situation, the original repository suddely disappeared, then came back under different name, then the playstore version repo got archived and now you also have the nel0xes’ new repository (for the play store version?) but no link to the play store version, so it’s confusing if the playstore version is even linked to it?
Don’t feel bad about that, it’s at least as confusing for everyone who’s been along for the entire ride.
Well done. Due to the general panic attacks, we now have two versions. I don’t know which one I should trust more.
In the meantime, I would rather switch to something completely different, if it were available.
Well done. Due to the general panic attacks, we now have two versions. I don’t know which one I should trust more.
nel0x has been around awhile and folk in this thread and on github have a lot of trust with them . additionally theyve been responsible for the play store releases for a long time. their repo is at GitHub - nel0x/syncthing-android: Syncthing - A Syncthing Wrapper for Android. ; from what im seeing this is the repo / build folk will be using for the time being, myself included.
long-term researchxxl’s code might be trusted but theyve done nothing to help build trust with the community that ive seen.
In the meantime, I would rather switch to something completely different, if it were available.
in the above folk mention syncthing tray which has an android release now. there are some notes in their docs about quirks with their android builds but it looks to be usable. this is what id recommend if you want to totally change apps. just be sure to read their android document on quirks and things to be aware of prior to setup.
To add to syncthingtray migration guide, be careful and use example instance first, syncthingtray Android version is still experimental. For obtainium usage the apk name inside the zipped release is “syncthingtray”
I’m still on nel0x gplay version, I’m just gonna wait for nel0x version release since I’m not confident enough in trying syncthing tray for now.
aarch64-linux-android28.apk
syncthingtray.apk
Do I feel some arrogance in here?
@nel0x i hope we can at least share our knowledge and improvements as time passes and code diverges.. have not see a java code commit from your side yet so i appreciate your courage to tackle this as a new app. looking through your repo history shows you regularly pulled the code from the forks upstream repo which now landed here.
lets now focus on real work for the app
Sad to see that this great project is going down.
Hi, landed here after doing a web search for the Android battery drain issue and reading issue 16.
I’m thankful people are stepping up and making things right, a signal that neither syncthing nor the android app are declining.
Governance and trust are “real work” and table stakes in an app like syncthing whose trust level and utility makes it a prime candidate for supply chain attacks. If I can’t trust syncthing, I would be better off crawling back to Dropbox.
Contributors who think this just a fun app to hack on can continue to do so, but I want people at the helm who understand the above.
I am personally invested syncthing-android continuing to work for a long, long time. I have been using syncthing since 2020 or so. Professional dev since 2013. I created an account to say, “hi” and also say I’m willing to lend a hand.
That depends on whether the quoted statement is true or false.
If I had a last wish … 
Therefore, I did hand over all my stuff to my inheritant @researchxxlresearchxxl inluding the com.github.catfriend1* apps, digital signing material and wish them the best to fulfill the mission of carrying on the Syncthing-Fork app. 
We have met in online gaming and developing modding code together for a level that tells the story of a research station attacked by some alien-like monsters. Two players do have to cooperate on fixing electrical devices, a low power emitting nuclear reactor and avoiding a bath in acid. If you stumble upon the game, say hello to us during our test ses@researchxxlions. 
@researchxxl Thank you for your will to take a try on coding. Without your work, the app would die until revival for a while.
To the community:
I am sorry to see how things developed during my absence.
THANK YOU for all those great 7 years we were together.
THANK YOU for - currently - 82k for following a genuine, transparent and reproducible release of the app with all its cat purring friendliness.
I’ll authorize every attempt to clean up this mess.
I’ll review the progress from time to time and if I find anything malicious going on, I’ll let you know here.
Edit:
Regarding @nel0x , they did not have any history with the Syncthing (Android) project nor an expressive public profile when they applied to take over the Google Play Store entry in Feb 2025. I accepted this and transferred - believing in good will and we agreed on their task to be publishing what was on my repository to Google Play after their review. If they now desire to make their own app, there is, unfortunately no way to clean up the confusion caused if it is called the same other than kindly asking them to rename it.
With all due respect, on the point of developer or tech savvy aspect, why won’t researchxxl publish his dev profile, complete the f-droid reproducible build, publish your and researchxxl’s public signing key, and IDK, the communication being silent is weird. Also whats about the issue that starts with “dont play with my desktop“ implying hacker getting into your computer, which info are correct?
the dichotomy of one big changelog vs many releases notes (Aves in contrast to, standard notes), i get it. what i dont get is the communication going silent. IDK anymore about cryptography, but Linus has his rage over email listing
OutOfTopic
(east bloc diverging from west bloc linux codebase [no idea about NK linux distro], Unicodia stance is fine, i like his approach since its linguistic, but it’s also not possible without neologism since u s spellings are more lingua franca than uk-en right now as su per po wer, but it’s a fine approach, linus is also justrified, since he lives in the u s, the agency is on his thr oat, and it will also jeopardizes the whole internet stack, so diverging east bloc and NK linuxes are fine, harmonyOS of chi na will probably help br ic tech stack or something similar, the xkcd comic of standardization)
OOT, and your silence. other could chime in, with the cryptography aspect, sorry for the comment, this is my main syncing app, so this is why this sounds urgent, and defensive, or just usual “reproducible build”, public signing key gpg verification, ways of devs to legitimate apps, confirm pdf, email. I might not produce any of this cryptographic app release aspect, but I do have keepass + syncthing workflow;
so I have researched cryptography before, but yeah with all due respect this is out of my scope, I’m gonna go with nel0x or martchus for now. this is kind of similar to how the linux codebase diverge after the triple a agency knock on linus door, so yeah at least this one doesn’t get that much coverage.
To compare even though abrupt, the forks and original devs communications are better in picocrypt vs picocrypt-NG, no silence, the og dev is kind of fed up with neural network but thats a different story.
DivestedOS went EOL, Ironfox and AXP OS for android take some of the projects into a new fork but with new names. havent see dialogues between them, but the divestedOS dev is live again with commercial profile, old repos archived.
while picocrypt will probably use his trademark for commercial release but still allowed picocrypt-NG to exist and provide FOSS community with a fork release. something like tachiyomiSY existing even tho Mihon exist, also because of QoL or features differences.
answering this might strengthened your defense/clarification, but it’s your decision to answer or not.
making an exhaustive chronology since your last commit up to researchxxl commit or dialogue might make this clear. I really dont get why you dont take picocrypt or divestedOS approach, archived repos, but still let others make fork of your work?
email or pdf gpg are out of scope. those 2, 3, or 4 questions are probably enough for clarification.
Either Nel0x or Martchus version, Martchus’ syncthingtray currently is still experimental, but aligned more with the desktop web-ui, some issues or bugs are problems on the android side instead of QT. while ATM, nel0x fork of syncthing-android and syncthing-fork of catfriend1 has more features. I think martchus’ syncthing-app of syncthingtray currently needs more beta tests.
I feel like most people following this would be most comfortable with @nel0x’s having the owner rights of the repo, and @researchxxl being welcome to contribute to that repo. This is solely based on what has transpired so far, where @researchxxl failed to establish trust with his communication. Of course having any communication from Catfriend1 before the repository was deleted would’ve prevented most of this, but that’s in the past. Nel0x seems to have the community’s trust on his side, and that’s crucial. Researchxxl can then establish trust in his work with his coding contributions, but speaking for myself here, I wouldn’t yet be comfortable with him being the project’s “heir”, even if his code is impeccable. This seems like the best compromise to me.
If I can add my 2c on how to peacefully resolve all this (which is basically what @nel0x and the Syncthing team have already come up with, I think), let us assume everyone is working in good faith. Then it should be no problem whatsoever if the @ researchxxl’ version is the “upstream“, and the @nel0x is the “downstream” which might pull commits from the upstream after inspecting them (and optionally may diverge a bit, too). The “officially endorsed“ version by the Syncthing project would be the downstream by @nel0x (as, to my understanding, the Syncthing project already trusts them). If, after a few years or however many is necessary, nothing problematic occurs, and everything works without any issues, one can revisit this situation, and potentially merge the two versions (and its maintainers) into one (there should hopefully not be many reasons for both versions to significantly diverge in the following years, so this should not be all that problematic). While not ideal, if @ researchxxl’ intent is truly just to continue developing the application, there should not be an issue with this approach. And this is the most straightforward way I can think of to slowly build the trust between the community and @ researchxxl while keeping the users secure as well, following the idea that trust must be earned, not given.
On the other hand, if there is a malicious intent (for example, there was already mentioned above that the credentials to @Catfriend1’ accounts could be compromised (let us assume every account, so even in here on this forum)), the malicious code will not reach the officially endorsed version by @nel0x as such commits would be (hopefully) caught by @nel0x.
Of course, this is all based on the assumption that @nel0x or other trusted community members are willing to verify the upstream commits to not contain anything strange. But it seems to me that this is the only option on how the two version do not diverge too much, and save everyone duplicated effort of developing the application side by side (as for the matter even @ reserchxxl said on GitHub: status · Issue #16 · researchxxl/syncthing-android · GitHub ).
To @Catfriend1: Thank you for all the years maintaining the client. I am sorry that you were having difficulties in real life that lead to you dropping projects such as Syncthing-fork. I wish you all the best in your life as well as future endeavours. Have a good one