Hey #flohmis! I just installed the new #yunohost package #flohmarkt 0.12.1~ynh3.

The flohmarkt code stays the same. @grindhold@23.social researched the issue that after upgrades to flohmarkt the clients needed to force reload the frontend.

To circumvent the problem nginx now adds a header to control caching. **Thanks for the PR to the yunohost integration repo by @grindhold@23.social!

The testing environment of #yunhost found an issue with using add_header in nested nginx-configurations and delivered a reference: https://www.peterbe.com/plog/be-very-careful-with-your-add_header-in-nginx

Thanks to the great work of all the yunohost contributers for that great testing environment!

The newer package can be updated or installed from the yunohost app store.

From the download counter on the release page at codeberg I estimated that there are between 30 and 40 #flohmarkt instances out there running on #yunohost.

(Who uses ZIP ? Well, the yunohost integration does and the counter went up by the numbers shortly after publishing the latest update to the yunohost app integration.)

On the wiki we have a list of ~20 flohmarkts. The list is meant for users to choose an instance and for admins to look for other flohmarkts to federate with.

I'd like to invite everybody to drop us a line to add your flohmarkt to the wiki: either as a codeberg issue or as a fedimessage or fedipost or on #flohmarkt IRC.

And even if you'd not like to be on the wiki page: federate with others to make your small ads more visible.

#Federation enables that #SmallAd​s show up on the other instances an instance is federated with directly. This gives every small ad some more reach.

My impression is that federation is extremly important to make the flohmarkts more successful as an alternative to the well know centralized services.

I opened an issue to discuss how to make federating easier without forcing anyone to share more data with the world than they do with the actual version of flohmarkt.

After an outage of #Signal (caused by a problem at #AWS) @Mer__edith@mastodon.world argued that a cloud provider is needed to run a service like Signal.

I answered that a cloud provider is needed, because Signal doesn't federate (and thereby build its own so called 'cloud').

I added that I doubt that by using a cloud provider Signal doesn't leak the social graph of their accounts.

I got referred to the #PrivateContactDiscovery by @newhinton@troet.cafe designed to protect the social graph which I simplified to hashing leaving out the use of #sgx part in my post.

I stated that I wouldn't understand how one could be sure that all which is guaranteed by using SGX really is like it is promised.

The only answer by @moehrenfeld@social.karotte.org is that I indeed didn't understand "Private Contact Discovery" completely.

It's frustrating to doubt and being left in the dark about the facts.

Today I learned something new: SGX is not meant to be save against physical attacks - or to phrase it different: SGX is meant to protect data if the OS is completely compromised, but the server is under physical safety and control:

…All three chipmakers exclude physical attacks from threat models for their TEEs, also known as secure enclaves.… (Nvidia, AMD, Intel)

…“These features keep getting broken, but that doesn’t stop vendors from selling them for these use cases—and people keep believing them and spending time using them,”…

…Those making these statements run the gamut from cloud providers to AI engines, blockchain platforms, and even the chipmakers themselves. Here are some examples:…

…The maker of the Signal private messenger assures users that its use of SGX means that “keys associated with this encryption never leave the underlying CPU, so they’re not accessible to the server owners or anyone else with access to server infrastructure.” Signal has long relied on SGX to protect contact-discovery data.…

Big thanks to @kyle@kylerank.in for sharing this post by by @arstechnica@mastodon.social: https://arstechnica.com/security/2025/10/new-physical-attacks-are-quickly-diluting-secure-enclave-defenses-from-nvidia-amd-and-intel/ !

Maybe my naïve assumption that you can only protect data on hardware you physical own and protect has not been so wrong at all.

I'd be happy to read arguments and opinions and corrections to the arstechnica article.

Just updated the #yunohost package of #flohmarkt to the latest release 0.12.1. All the new features of 0.12.0 are included.

Thanks to the flohmarkt developers and supporters for their ongoing work and congratulations to the nlnet grant!

https://apps.yunohost.org/app/flohmarkt

On my testing #Librem5 running #Mobian I had obviously installed a workaround to get echo cancellation for calls by using #pulseaudio for audio. I had forgotten about it and after some update or hardware tinkering sound just didn't work anymore.

I found out that I knew not much about sound and while trying to understand how it is supposed to work I wrote some of my findings on the Librem5 community wiki.

I'd be thankful for corrections and additions to be able to move the page soon out of the work in progress section.

Just started a list of compatible devices for #tangara on the forum. There's also an issue open asking for some place to add information about the tangara audio player.

I never owned or used an Apple iPod for listening to music and I really like the Tangara playing as an device independent of my phone.

If you're wondering about the FSF starting to work on Android and are interested in an opinion about the technical options they have about their endeavor, please read Caseys thread about it.

This is the insight I do not have, because I'm no developer.

If you do not follow her already on the fediverse or elsewhere: my impression is that she is bringing up devices with PostmarketOS at an unmatched frequency . This makes her opinion exceptional interesting, because she probably knows very well about which blobs we're talking.

After thinking a bit more about the situation and the idea of cleanroom reversing I wrote down this thought.

Original post deleted, because I accidentally used the wrong pronoun - sorry, I hope I didn't hurt your feelings, @cas@treehouse.systems! Thanks for making me aware, @kate@treehouse.systems!

https://chrichri.ween.de/o/cffc6733c9a74ae2a3ad3ccc8c8a0923

@fsf@hostux.social @fsfe@media.fsfe.org

Every few hours my thoughts start cycling around the idea to free Android.

About reversing blobs in a cleanroom I had the following thought:

I pretty well know the SAMBA project, because the company I work for delivers support for SAMBA and takes part in its development.

In my opinion SAMBA is an example for a very successful attempt of reverse engineering closed source. In the end Microsoft had to give in and started to work together with the SAMBA community in some kind of manner and everywhere you find smb you'll find any device (nas, workstation, whatever) running SAMBA or anything based on the SAMBA code.

This success took part in a very slow moving environment. Microsoft designed SMB and Active Directory for huge networks running in a stable and very slow moving manner. This gave the SAMBA team the time to get market shares for their FLOSS solution. They had the time to make it work to a point that people looking to talk to a Windows Network without having to run Windows and/or pay license fees started using SAMBA (and paying SAMBA developers to enhance and adopt the code).

Compared to the environment the blobs for Android devices live in it becomes clear that this SAMBA success factor - having time - will not apply for the FSFs project to reverse these blobs.

Developers of these reversed blobs will not be payed by any market participant to enhance or alter there blob replacement - I'm not able to think about any good reason. Companies wanting to sell a product for profit will just base their effort on Android or iOS. Why should they have interest to replace any of the working mobile ecosystems?

I'm still wondering why people at FSF opted for this direction instead of helping to build a new ecosystem running at our own speed making us independent of decisions taken elsewhere.

https://librephone.fsf.org/

Free the last bits of "anything Android"?

My positive thought about this is that #PostmarketOS and #MobileLinux in general will profit from any public knowledge about hardware it could run on.

If I understood correctly the money for doing the work on the #Android blobs is donated by John Gilmore. His Money, his decision where to put it. And there is a positive effect, but there is also a negative one:

Android is based on ideas by #Google. To free it we'd need to fork it and adopt it to different ideals and goals. Android is designed to maximize the profit of Google.

It is not designed with the users well-being and interests as the primary goal.

Just replacing blobs in Android keeps the ecosystem the same, promotes Google and their goals and leaves the control over design decisions for Android in Googles hands.

Once a device is freed by hard work of a few engineers it will be old, it will be uninteresting for people looking at Android and the latest shiny hardware running it.

But still - Mobile Linux will make good use of those devices as free OSes in general do when it comes to hardware left behind by commercial OSes.

@fsf@hostux.social @fsfe@media.fsfe.org