My use case was probably simpler than some peoples use of syncthing as I just use it for backing up photos/messages/settings and dont need it to be instant.
My only issue with FolderSync is that its proprietary but its the only option i found that worked well. The various rclone frontends that exist also didnt work nicely with the webdav server I use so I settled on it, its very polished so I dont mind too much.
10 euros for an Android license for or $28 (yes they use two currencies on one page) for a desktop license. The free ad supported version on the play store has over a million downloads.
it looks very much like this
if it had been handed over to someone with a long-lived github account, who was known in the community it would be one thing
but a 3 week old account? I'll be staying the hell away
[Edit: The GitHub repos are called "syncthing-android". The Android apps are called "Syncthing-Fork" or "Syncthing-Fork Wrapper", which adds to the confusion.]
If I recall, there used to be a syncthing-android app on Google PlayStore. That was discontinued by @imsodin in Oct 2024 (https://forum.syncthing.net/t/discontinuing-syncthing-androi...).
There was a version of sycnthing-android on F-Droid. I don't remember who maintained that. I have version 1.30.0.4 installed. But I cannot find any information about that version anymore.
The current version on F-Droid is 2.0.12.1. That seems to be maintained by a fellow named @researchxxl. Apparently @researchxxl claims to have inherited the source code and signing keys from a person named @Catfriend1 (Not sure who that is, the maintainer of version 1.30.0.4?)
There is another fellow named @nel0x who seems to be maintaining a different version of synchthing-android? (Edit: Here it is, https://github.com/nel0x/syncthing-android, which says that it is a fork of the one maintained by @Catfriend1).
Can confirm same case here. App was installed from f-droid, no longer linked to the store.
When google locked down on file apis a year or so ago, the official syncthing-android pulled out of google play, but syncthing-fork stuck around in fdroid as the fork was for personal purposes, and they were using fdroid for distribution in the first place.
This change in ownership is new to me, but I'm also not surprised it happened as syncthing-fork was always a personal project.
Looks like the original repo of syncthing-android, (https://github.com/Catfriend1/syncthing-android), which was maintained by @Catfriend1, now redirects to the one maintained by @researchxxl (https://github.com/researchxxl/syncthing-android).
The problem seems to be that no one in the syncthing community knows who @researchxxl is. The account was created only 3 weeks ago. There was no communication about how the transfer took place. Was the transfer actually authorized? Did @Catfriend1 get hacked? People are worried about a backdoor hijack attack similar to the XZ libary.
There's a long discussion at https://forum.syncthing.net/t/does-anyone-know-why-syncthing.... It is too long and complex for me to follow. (I tried to get an LLM to summarize that thread for me, but the output was not helpful.)
It is unclear what sycnthing-android users are supposed to do right now. I am staying at version 1.30.0.4 until things become more clear.
This is a particular concern because the syncthing-fork is coded to require full storage access, iirc for compatibility with certain phones. Idr, went through with Claude and iterrated through a diff of everything that between Catfriend1's changes and the original repo. The broad access really isn't necessary on most phones as I refactored the flag, compiled the app and installed it with no problems. I ultimately decided to go with the official build to make updates easy, now hmmm. Troubling when the trust gets so dilluted.
I’ve read through a number of the GitHub/Gitlab/Forum threads and while I’m not saying anything new:
You couldn’t script a more suspicious transfer [0]. That fact is maybe the most compelling reason to assume it’s actually above board, if there is malicious intent, it’s being poorly disguised. To make matters worse, both Catfriend1 and researchxxl appear to be very bad at communicating (both in language and speed). Yes, Catfriend1 has surfaced and says they did transfer the repo/signing keys. Why that couldn’t have been posted at the start of this is beyond me. Researchxxl seems to not be a native english speaker and I tried to take that into consideration but I’m increasingly finding it difficult to give them the benefit of the doubt. They seem… immature, that’s the best way I can put it. They certainly don’t seem trustworthy nor have they made any attempt to address raised concerns. I wouldn’t touch their releases based on what I’ve seen, way too much access and way too little trust.
[0] Repo redirected to brand new account/repo with no notice/announcement from original owner. Furthermore, evidence that the signing keys were transferred and users might be at risk of malicious updates (see the many examples of Chrome extensions that were quietly sold and turned malicious).
embedding-shape•10h ago
sevg•9h ago
I thought this comment was strange at the end of Catfriend1’s post:
> I’ll review the progress from time to time and if I find anything malicious going on, I’ll let you know here.
That’s absolutely not something you say when you trust the person you’re handing things over to :s
sneak•8h ago
sevg•8h ago
bgbntty2•8h ago
Trust is not transitive, nor should it be. We (the users) trust the previous maintainer. They trust the new one. We don't (naturally). The old maintainer says they'll review the new one's work, so we'll have trust the old maintainer (mostly).
Not that the whole trust system can't improve in various ways in general. But for now we have to trust someone.
sevg•8h ago
The statement didn’t seem reassuring.
It’d have been reassuring to hear something like “This person has been a committer for X period, and has demonstrated Y and Z.”
> They trust the new one.
Well my point is it doesn’t sound like they actually do trust the new maintainer. Maybe just poor choice of words, but it didn’t fill me with confidence.
altairprime•8h ago
I suspect a lot of folks would be horrified at how typical the former maintainer’s approach to trust is in actual reality. It ends up being necessary because there are maybe a single digit number of people in the world who are willing to commit to long-term project maintenance (beyond their own pet peeves, anyways) at all, and with the general hostility towards compensating anyone for their work in software, it’s not like a maintainer can afford to hire and develop a protégé. This is how maintainership worked in CPAN for decades and, barring a culture shift towards paying project maintainers for their maintenance effort, it’s how it’s going to continue working in most projects as us maintainers grow tired and fade out.
bgbntty2•7h ago
Although I agree if the new maintainer had some creds, it would've been better to use them in a similar reassurance like in your example. But it's hard to really vouch for someone, even if they've made X commits for the past Y years, etc.. Lots of examples here.
If it's still a random/(pseudo-anonymous) account you're trusting, unless there have been some real life appearances or if it's an account that's been proving itself for years, you can only trust them so much.
Basically I agree the message could be interpreted as "I don't trust them, so I'll be on the lookout for anything malicious", but, honestly, at first I just read it as "I trust it, but you can't really trust anyone, so I'll still be on the lookout".