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

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.

Interesting. A level for which game?

hi together

i am now taking a heart and time to reply to your questions but still a little scared that rough voices hit me here.. well i believe most of the syncthing community is friendly and nice :slight_smile:

my intention is to continue the mission and goals of the syncthing fork app catfriend stated when they started distribute the fork on google play fdroid and github in 2018

Goals of the fork:

- Develop and try out enhancements together with the community.

- Release the wrapper more frequently to identify and fix bugs caused by changes in the syncthing submodule

- Make enhancements configurable in the UI, users should be able to turn them on and off

Comparison between upstream and fork at the time of writing this:

- Both contain the syncthing binary built from the official source at GitHub

- Syncing functionality and reliability depends on the syncthing binary submodule version.

- Only the wrapper containing the Android UI is addressed by the fork.

i am happy that nel0x has reached out to have another chat in private after first deny working together on the researchxxl repository.. atm we have different opinions on how to go on but i let them time to think about a solution that may fits us both or make their plan on going on their way..

i have asked them what their plans to contribute to the app are and if they might fit or not fit with catfriends original mission.. for example contributing code - solving issues - publishing - sth else

please be patient and do not pressure one of us.. i believe we both do our best to solve the situation the best way each of us or we can :slight_smile:

also cool to see security researchers recently posting about the researchxxl repo if you sort your search results from newest to oldest.. they did check the changes between 2.0.11.2 and 2.0.12.1 many many thanks for this and keep on!! this is not meant you should trust me now more than you did before but deescalates the threat aura fog

here is some plan to solve the unclear situation which i appreciate feedback on from app users if they think it will satisfy or not

  • researchxxl repo holds the designated and ongoing project with code issues and releases for the syncthing fork app as wished by catfriend the former maintainer and owner of the projects name

  • we will slightly rebrand the display name of the app to syncthing fork wrapper because imo this was the most misunderstanding for years and not wisely chosen by catfriend to make clear it is not confused with the original go written syncthing.. the app description already tells that it is just a wrapper.. and hopefully this might also help support tickets which before arrived at catfriend because users did not know which is the right area to put them - wrapper repo or syncthing repo

  • users can expect to get the same app if they read syncthing fork wrapper or com.github.catfriend1.* on release artifacts as they got from catfriend from 2018 to 2025 now.. this in mind catfriend signing keys will be used to allow friction free upgrade

  • for reference and security researchers to be able to verify if a published app with the name syncthing fork wrapper in it i put signed release artifacts as immutable github releases to my repo in all variants that users are known to have already installed that might be apk aab and split apk.. those can be analyzed who has signed them and easily extracted and compared by common tools like 7z.. this can be binarly compared without consuming much time because the builds on my repo are reproducible and can be compared against releases on apk mirror sites, foss stores and so on

  • so anyone can make their fork or rebrand of the app but if the contents do not 100 match our upstream they are forced to distinguish their work clearly from what users expect to be from the catfriend successorship

  • i welcome contributors :slight_smile: contributions are very welcome.. help in issues or support as well.. if we get more people involved i might ask to move the project to the syncthing org which would be a good idea in the longterms when theres more commits of multiple people there

  • the current state of the repo is not what i read of some peoples posts on social media and here.. please check yourself and realize that most.. lets say 90 percent.. of the work was done by catfriend between 2018 and 2025 regard the syncthing fork app after they forked the official syncthing android app in 2017 (i hope their notes are accurate because citing them)

  • from my pov nel0x is still unknown to the community because pulling exactly catfriend commits to their repo but i am happy that im getting to know them now by chat and can form an opinion of them and their abilities.. this was the simple reason i did not accept their invitation to just continue at their repo no offense was intended.. with nel0x on board we would be able - if they agree - to release one syncthing fork app to fdroid github and google play that would be 100 percent identical the same and verifiable by the community.. nel0x would also be in control as a reviewer as i do not have access to their google play.. the community would be assured that the reproducible build released on researchxxl repo is identical to the google play offered version by binary compare made possible.. beside the advantage this has downside for nel0x themselves they could not run their own brand of the app this way with another strategy for example feature set in the longerm in mind.. but i promise to be open and willing to accept deeper changes as contributions to the app as a tryout release candidate awaiting community feedback if they would want to change something fundamental in the future on my repo.. just to take the fear if they read this post - i would not block deeper changes by them nor force them into the need to make their own app.. that promised with the community in mind as i guess you users reading this do not want to end up with two different apps where features deviate

my plans to work on the app

  • solve that nasty battery problems on the v2 track

  • improve the app notification in the status bar it seems useless to me because i cannot see if syncthing is running or not without pulling down the bar :-/

  • migrate parts of the ui to material 3

  • solve some support issues

  • do release candidates to get your feedback and a monthly stable release

17 Likes

@researchxxl Welcome aboard :slight_smile:

Are you a modder? What is the game you and @Catfriend1 were working on together? I am crazily curious.

1 Like

Hi Jonas, welcome to the Syncthing community and thank you for your post.

You are right that @Catfriend1 chose you as a successor for his work. If I understand you correct you feel entitled to decide what happens with a Syncthing wrapper for Android in the future. But the discussion in this thread is beyond that already. There is a tendency to have this wrapper under control and in the repo of the Syncthing Foundation @calmh . There the wrapper for Android is in charge of an organization. This is even better than what @nel0x suggested to you in the beginning, to have a new organization in Github.

I hope the Syncthing Foundation will go that way and you may as others become a contributor to that true Syncthing Wrapper for Android.

5 Likes

Good proposals from all parties; I hope to see them all converge.

Up until now, nel0x’s version is a downstream; as a user, we can be sure that someone has reviewed the code when we track that repo. If the gatekeeper (at least for Google Store) works on the same repo, that might help streamline things.

Another issue I see is that nel0x and researchxxl must keep the same pace as the project progresses. I’m not sure if that is practical.

But that would mean no Syncthing Spork :cry:.

1 Like

First and foremost; thanks for the reaction. Ideally, this all should have happened before Catfriend handed over the repo, to mitigate a loss of trust.

I think you may step over one big hurdle here: trust. Not to be negative, but the whole process so far has been suboptimal to say the least: no communication prior, no real clear path for weeks, nothing known about the new maintainer, everything handed over to a new Github account without any background visible/known (other than that you modded a game?).

To be very blunt: nobody can currently “know” (although we can never really know for sure, that’s another story) how capable you are, and how well your intentions are. This while, potential, very sensitive data is being handled by the application (wrapper or not).

I still do not get the feeling that this “worry” of users is completely understood.

In all honesty, I won’t install the Android app till there’s a (non-archived) version under the Syncthing Org umbrella, again. It’s been (with all due respect) a bit too chaotic. I’ll just do it in other ways, for now.

I doubt this adds much, really. “Wrapper” is on its own a big vague, at best (esp given the international nature of the users, with all different levels of understanding of the English language). “Syncthing” in its entirety is still in the name, probably implying a thing or two to lesser informed users.

I’d suggest to bite the bullet and think of a completely new name. Away from the fork, away from anything directly including “Syncthing”.

7 Likes

I guess that makes some sense. With Syncthing Tray I have the same problem that sometimes people report issues of Syncthing itself. However, I would also never put “wrapper” in the name of Syncthing Tray. It just sounds awful. It also probably conveys less meaning to the average user than we (who already know what the term means in this context) intuitively assume. My approach would/is the following:

  • Have an “Issue with Syncthing itself” option in the menu that opens when clicking on “New issue”.
  • If that’s not enough, add a remark in the ticket template itself.
  • Accept that some kind of issue triaging effort needs to be done on “wrapper” level. It isn’t that much effort to simply tell users that they need to file an issue with Syncthing itself. (Or that they need to file an issue with, e.g. Qt. It is not like Syncthing is the only dependency this applies to.)
4 Likes

To be honest, I think the word “wrapper” is completely meaningless to a non-technical person. They will still require a much detailed explanation to understand the concept. The word is also difficult to translate into other languages.

6 Likes

Perhaps “runner”?
e.g., Thinksing: A Syncthing runner (replace Thinksing with any name)
While the term ‘runner’ may not be strictly correct, it’s good enough to convey the message.

But hey, don’t get too distracted with the names; they are some details that can be settled later.

1 Like

Brilliant. Thank you @researchxxl for listening and posting thoughtfully. We all very much appreciate your efforts (even me, who has posted with significant reservations). As an owner of an accidentally popular open source project myself, I know it can be a tough spot to be in, not least emotionally as you try to juggle all the conflicting demands. Good luck!

2 Likes

since wrapper is the intermediary between 2 software, or to mediate. maybe UI, e.g., UniGetUI. Syncthing (Android) UI

either space or hyphen. hyphen is used for CLI directory.

other examples are still too vague, I think interface is a common enough word, its not as technical as wrapper, but not as vague as runner, tho runner is very common and exist in quotation example.

usually brand needs to be unique, otherwise there are some cases of more words to avoid trademark problems: sample-fork, sample-specific but common enough word, WingetUI>UniGetUI. you could open pull or issue of this in github issue, I think thats the way to go.

researchxxl open new thread of syncthing-placeholder as title just like Martchus syncthing tray, so this discussion is not derailing and out of topic from its title and category.

open pull or issue in github with reference to this forum thread, so feedbacks are here where the community choose its discussion place instead of github, like ente using it for roadmap. but the pull and issue still include reference to this thread. feedbacks in forum>pull or issue citing it from forum.

You need to discuss this a lot with other members here, trademark, app package name are hard to change, github or other repo also has big problem with changing name. what past is past, catfriend as acc transfer is fine. but for repo i think you gotta do cross repo backup and restore, instead of changing name. package name is also important. no pressure tho it matters, because without clear package name and trademark name, this wouldnt fly as app release. no deadline for you and other contributor, its just a note for myself and feedback. xz util, linux codebase branching off, all as open source activist to say the least. i might be too harsh, but sadly i know well cryptography enough to know, this is the approach. tho my manner is too blunt.

anyone could add more suggestions to the trademark, also important so im gonna ping @researchxxl you will have to make new thread specifically for your app discussion like martchus did. this discussion has went really out of topic. thats all.

examples and references:

(computing) An application for mobile devices made wholly from an existing website or platform, with few or no changes made to the original version.

wrapper

(object-oriented programming) A construct, such as a class or module, that serves to mediate access to another. We need a Perl wrapper for this C++ library.

edit:

IDK, cryptography well enough. only enough to make keepass + syncthing guide WIP. i actually know this problem well enough because 2 of my old social media accs were hacked.

@researchxxl I think the initial radio silence, paired with users’ concerns about the current situation, caused a lot of the bad vibes. Presenting yourself and your goals openly to the community remedied that :wink:

I hope that you and @nel0x can agree on a path forward that works for both of you. My dearest wish for the future is a single trusted repository under the Syncthing organization.

Having a maintainer for the project has been an ongoing struggle in the past. Since you’re both willing to step up, it would be wise to join efforts. Having a bus factor greater than one and reducing stress per maintainer are not to be underestimated.

6 Likes

Which would suggest iOS + Android. I don’t think there are any plan for an iOS app,

The name doesn’t address the original concerns in the first place; I don’t think that’s a serious suggestion.

researchxxl want to convey to users that there are two separate pieces of software: Syncthing and whatever we call this app on Android; the app happens to contain the Syncthing binary. If you have an issue with Syncthing, you should probably open a thread on the Syncthing repository.

The name or term used to describe the app should convey the idea of separate entities and their relationship. I’m not sure why context in conversations sometimes gets lost so easily, perhaps due to the fast-paced way we tend to consume information nowadays.

1 Like

Can you guys stay on topic?

I subscribed to this thread too follow the worries about the change of ownership of the project, not to be notified every day of a bunch of guys debating about what they think its new name should be, no offense.

Please create a new thread to discuss this.

21 Likes

I’ve been using syncthing‑android 1.27.3 on Android 16 ever since it was removed from Google Play, and it remains very stable.

Researchxxl prefers GitHub, not sure if this still is effective.

Why not going on our good old way: keep github clean and quiet for real developers, and the forum here as a central cross-platform for community support to simple users? When a question here turns to look like an issue, there are many chances there is already an issue posted in github by an advanced user.

Bye-bye @Catfriend1, many thanks from everybody here (I hope) for the kind job. I also hope you’re alright, young people are so impatient they do not yet know time passes too quickly :waving_hand:.

2 Likes

How’s syncthing performance on termux like? Does it manage to stay up and running in the background, without getting killed by android? How’s the battery usage of leaving an app like termux running syncthing running in the background?

@monero-money Syncthing using termux does not, of course, have the bells and whistles of Syncthing-fork but is fast and efficient and the GUI is accessible @localhost:8384 in Firefox. Termux needs permissions (termux-setup-storage) to access local folders. I’m on Android 15 and have not noticed excessive battery drain < 1% after two hours, but termux does get killed by Android after that time, which is ok for my use case. Syncthing is using default vales for the two folders I sync to my Rasberry Pi4. Termux’s repo was recently updated to the current v2.0.12.

2 Likes