Hans-Christoph Steiner @eighthave@librem.one

@mro I agree, highlighting the role of the signing key seems key. An app signing key is in effect a pseudonym. The hard part is that there is that there is no concrete way for users to verify what the key management practices of the developer are. Judging that from the outside means looking for any signs that the signing key was misused. If a dev wants to hide misuse of their signing key, that is pretty easy to do. For example, they could sign malware and only ship that to targeted users

@jexner your formulation seems like its going the right direction. On one hand, in the world of financial accountability, "know your customer" and showing government ID is normal. Borrowing an established practice makes sense when it works, but it doesn't feel right to apply that to developing software. I don't think the requirements are the same between finance and software, although sometimes similar. I haven't found a good breakdown though that maps that out.

@jexner Can the human be anonymous while the "dev" is public? Clearly, we want the apps we use to be maintained by entities that we can trust. Are given names required for that? I think clearly not. For example, non-profits. People trust #EFF as an entity, even without knowing who everyone works there is, and whether the staff changes. So the entity can be trusted separately from human participants. I think developers are similar. Many trusted FOSS contributors operate under pseudonyms

@rene_mobile @marcprux @fdroidorg @GrapheneOS @lehtimaeki @ottok @grote

You are all people who have specifically thought about this kind of stuff in relation to software distribution, what do you think?

At the core of #AndroidDeveloperVerification are a couple potentially useful ideas. #Google has entirely wrapped them in a pile of anti-competitive garbage designed to defend their massive #monopoly profit margins, but nonetheless, those specific technical ideas might still be useful. #iOS's "notarization" is basically the same. That leads me to ask the key question:

What would a #FOSS-respecting system of #verification look like? What #identity info is useful for trusting the #developer?

@exitcode @fdroidorg Good to hear! I'd love to see more feedback from users who need "full manual" mode. Replying here is good, posting to https://gitlab.com/fdroid/fdroidclient/-/work_items/3171#note_3483200283 is even better (that way we don't lose track of the feedback).

@exitcode @fdroidorg "Check for updates" is on the menu on "My Apps"

@aerique @waag oops, that's Volla not Jolla. So confusing. Volla is making their own version of Play Integrity, and Jolla makes SailfishOS, which is proprietary.

@exitcode @fdroidorg In 2.0-alpha11, a "Check for updates" menu item has been added. How does that work for you?

@Chapz addictive patterns are now well established in software. We need to work to get rid of them, doesn't matter if it is FOSS or not. To me, the point of social media is to communicate with people efficiently in specific ways, not to kill time or "engage" people. The focus needs to shift to that.

@aerique @waag For what it is worth, Sailfish OS isn't free software and they are working to implement their own version of Play Integrity. That's totally the wrong idea here: we don't need a European monopolist to replace the US one. We need healthy software ecosystems that put the user in control of their own devices.

Finally, it looks like there might actually be some tiny measure of #accountability for the pushers of #AddictiveDesign. #BigTech and universities like #Stanford knowingly created #design techniques with the publicly stated goal of making #software #addictive. It worked

https://www.theguardian.com/technology/2026/jul/10/eu-accuses-meta-failing-tackle-mental-health-risks-addictive-design

I can only hope that the #EU will keep pushing based on the #DigitalServicesAct and follow through. At least there is the tempting possibility of a fine of 6% of revenue that should keep them interested

For all those that rely on #AI, I had a nice reminder of how it can really make bad errors with full confidence: #Google #Translate consistently translated the German word "Inland" as "Germany". It was a document from the Austrian government. "Inland" means "domestic". And this is translation, which has been worked on much longer than all these LLM thingies.

@cassidy I hear you about reliability. I gotta say Matrix/Element is pretty solid. As for calendar events, Google is reliable for calendar events when everyone is using it. Those outside of Google regularly encounter long unfixed bugs on Google's side, like their shitty handling of UTC.

@danialbehzadi that would be great! Here are two examples of how people did that:

* https://f-droid.org/2022/04/25/from-user-to-contributor-and-beyond.html
* https://cketti.de/2021/01/14/my-first-year-as-a-full-time-open-source-developer/

Sadly, in Europe/US, I think most people believe they can't donate to someone in Iran because of sanctions. It would help if you explained the details of that. I don't know the answer. One thing to check would be if you are eligable for NLnet grants. They don't fund work on Debian directly, but they do fund work bootstrapping key tools like Android SDK or Gradle

@lehtimaeki At this point, Thunderbird is maintained by a tiny team for the size of the project. And it seems really hard to maintain FOSS email clients these days, since there aren't really any better options, although many have tried. I hope some digital sovereignty money flows towards desktop email clients in a big way. We need them to reclaim email from Google, and it isn't _that_ hard.