Lots of projects with good security track records host key servers in a "member's house". That said, the F-Droid buildserver is not hosted in anyone's house.
There are two key concepts at play here: "least authority" and "infrastructure as code". The buildserver host is sensitive security-wise, but easy to set up an instance. We have multiple instances running, and spin up new ones from time to time. For production infrastructure, there should only be enough people with access to it as are needed to maintain it. No more. If a sysadmin goes rogue, we can always just spin up a new instance elsewhere with a new maintainer.
The limiting factor for upgrading our buildserver is finding a trusted, skilled sysadmin to physically install, setup and maintain new hardware at the high level of security that is needed for a release buildserver for a project like F-Droid. It also needs to be in a trusted physical location. Hetzner is definitely not that.
F-Droid is working to figure out how to manage secure backups in a way that is controlled by a free software community and is as secure and usable as possible.
Interesting points, I agree the Updates tab could do better there. Update All is implemented if you have F-Droid Privileged Extension installed, it could also be implemented when it is directly installed, if someone wants to contribute there.
Hey @pserwylo, great to hear from you, and I especially appreciate your message here with the background. And I'd like to highlight your point that there is much less contributor time than people imagine. If anything, the F-Droid client UX design process back in 2016 has proven to be an immensely efficient exercise it putting together a UX that still works decently. Plus we managed to predict that bottom nav would rise in popularity and those sliding sidebars, which were recommended back in 2016, would fade.
You're of course welcome to contribute again! The hard part is that app stores are large and complicated apps, when done fully, so that makes it hard to contribute to. We do mark issues with "first-timer" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... and "help-wanted" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... if anyone is looking for a place to jump in. I think we can also see this in all the various other clients like G-Droid, M-Droid, Foxy, Droid-ify, NeoStore, etc. Many rapidly stop being maintained, and others leave out key functionality like localization and automatic mirror selection because it is a lot of work to implement. The new libraries should make it a lot easier for forks to implement these features.
This is a full revamp of a bunch of the key guts of the app. We hope that other F-Droid-compatible clients like Classic, Foxy, NeoStore, droid-ify, etc. can benefit from this revamp as well: we've split out this core functionality into libraries. This should fix lots of stability issues. I think it is also important to point out that the official F-Droid client is stable for the core contributors, and that's mostly because a) we are the devs and we fix the bugs we encounter, and b) we report the bugs we can't fix.
I think most F-Droid contributors are using Google-free devices these days, so that's where it works best, especially when built into the ROM like CalyxOS, Lineage-for-microG, etc. Unfortunately, that means we pay less attention to how things run on Google devices. So if you're running F-Droid on a Google device, please be sure to report issues so we are aware of them!
