Med vissa skillnader och begränsningar.

Nostr är byggd kring att data rekommenderas att spridas över många reläer, vilket ökar - men också naturligt balanserar - lasten, och eftersom varje relä lagrar datan så kan de alla skicka ut den till klienter också. Olika NIP:ar hanterar grupper olika i protokollet, men alla har någon idé runt att många reläer kan hantera samma grupp. Och användare kan nås över flera olika reläer samtidigt också.
Fluxers beskrivna design däremot kräver att all data för en specifik användare eller rum måste skickas till och läsas av just den noden som ‘äger’ användaren eller rummet, vilket betyder att oavsett vilket relä du går igenom i deras “federering” så kommer all datan i slutändan gå mot samma nod, vilket centraliserar lasten.

Edit:

För att beskriva lite djupare runt problemet;

Anta att jag har en nod som heter 'a, och det finns fem servrar/reläer A, B, C, D, och E. Anta sedan att varje relä har 50 användare som är intresserade av mina meddelanden. (d.v.s. i Nostr har en subscription, och i Fluxer är med i rummet)

Jag skickar nu meddelandet “Hej” med min nod.

Med Nostr så går det meddelandet ut till de reläer jag pekat ut (A-E i det här fallet), och varje relä tar sedan och vidarebefodrar det till de användare som är intresserade. Min nod - 'a skickar då ut fem utgående meddelanden, och varje relä A-E skickar sedan ut kopior av meddelandet till sina 50 användare.
Totalt har min nod hanterat en förfrågan - skicka meddelandet “Hej”, och skickat fem utgående meddelanden till federeringen.

Om jag nu gör samma sak i Fluxer; D.v.s skriver meddelandet “Hej” i ett rum i min nod.
Då kommer det meddelandet gå till min nod - 'a - som kommer skicka ut det till varje användare på varje server/relä, (A-E) eftersom jag äger meddelandet. Så min nod 'a kommer då behöva skicka 50 kopior till användarna i A, 50 kopior till användarna i B, 50 kopior till användarna i C, etc… Totalt har min nod fortfarande bara hanterat en förfrågan - skicka meddelandet “Hej”, och sedan skickat 250 utgående meddelanden om detta till alla intresserade användare.

Om en av reläerna - säg A - nu helt plötsligt förlorar länkar för sina användare, på ett sådant sätt så att de måste läsa om datan.
För Nostr kommer det då betyda att A behöver skicka ut 50 nya meddelanden till användarna som är ansluta till den med den existerande kopian. Min nod 'a märker inte detta alls.
För Fluxers beskrivna design däremot så har inte A rätt att lagra mitt meddelande, så alla användare i A måste nu få en ny kopia av meddelandet, vilket betyder att min nod 'a behöver skicka ut de 50 kopiorna igen.

Nu har jag då med Nostr fortfarande bara skickat 5 utgående meddelanden totalt, men med Fluxer har jag behövt skicka 300, och kommer också behöva fortsätta skicka fler kopior allt efter tiden går.

Problemet med delegerad auth / relä - om de inte lyckas bli övertalade att faktiskt göra äkta federering - är att alla själv-hostade servrar då måste vara kraftiga nog för att kunna hantera alla andra användare på alla andra servrar också, eftersom alla användare pratar direkt mot alla servrar de interagerar med.

Mina invändningar är mer runt hur folket beter sig kring det här än hur projektet i sig fungerar.
Men även där så lutar det mot att deras “federering” kommer vara en egenutvecklad lösning som är mer lik en multi-anslutande klient med delegerad auth än ett faktiskt federerande system.

Om man läser i de diskussioner som skett kring federering i projektet så har det redan ratats att använda någon W3C eller IETF standard för federering, så ett egenutvecklat protokoll av något slag ser troligast ut, där kommentarerna också lutade hårt emot att federering med icke-Fluxer mjukvaror sågs som en bugg mer än en funktion.

Det lät rätt mycket som att “federering” egentligen kommer betyda delegerad auth, där din klient - kanske med hjälp av ett relä på din instans - pratar separat mot varenda server i federeringen, istället för att bygga en faktiskt federerad lösning.

Lösningen på att en centraliserad kommersiell plattform ställer till problem för sina användare är verkligen inte att skapa en ny centraliserad plattform, speciellt inte om den också planerar att bli en kommersiell produkt.
V har redan bevisat att det går att skapa distribuerade/federerade lösningar för det här, som då också är helt säkra mot problemen som Discord just nu uppvisar. Det skulle vara mycket bättre om folk fokuserade mer pengar och utvecklartid mot sådana lösningar istället, så att vi inte blir sittande i den här sitsen igen i framtiden.

Considering this is anubis, the project created explicitly to block AI crawlers?

I absolutely love that zip-tie mounting solution, it’s the kind of thing I wish I saw in more homelab setups.

I really do hope that Funkwhale get their 2.0 release out soon, should make self-hosted Spotify-like stacks simpler to do, and the fact that it works for creation and distribution as well is great.

No longer an assumption - from itch themselves: https://itch.io/updates/update-on-nsfw-content

Assuming that this is due to pressure from VISA/MasterCard - like it’s been with Steam.

It’s patently bizarre how a company whose only purpose is transferring money from account A to B can then arbitrarily decide what people are allowed to buy and sell.
It’s one thing to refuse to be an acceptable payment method for NSFW games, but to forbid the store from selling them at all? That’s just megalomania, and a great pointer to why monopolies (and duopolies) are A Bad Thing™

Interesting, that’s definitely not what I’m seeing from regular use. Are you running any added applications? LDAP? SSO? External mounts?

Are you looking at data rates or IO operations? Because this is almost exclusively stat queries, i.e. inode queries.

Oh yeah, CPU usage is basically zero, and memory usage of the PHP code itself is also basically nil compared to other software I run. It’s just the sudden storms of IO requests that causes issues, and since those come over a network pipe it causes issues for other pieces of software as well.

Again, it works until it requires reloading, i.e. the next update of any component or the next restart of the server.

I’m also running an inode cache on the client side, on top of the persistent opcache, but due to the sheer number of files that Nextcloud consists of it still generates a frankly ridiculous amount of calls when it needs to invalidate the cache. If you’re running on local drives then that’s likely much less of an issue, regardless of what kind of drive it is, but this is hosted on machines that do not have any local storage.

Yep, those values are actually somewhat tame compared to my own cache tuning, the issue remains that the code requires reloading PHP files from disk during runtime in order to support applications and updates, which - even if it doesn’t happen often - causes IO storms that temporarily break both Nextcloud as well as other software.

Currently working to move away from Nextcloud myself, it’s PHP nature causes IO storms when it tries to check if it needs to reload any code for incoming requests.

All OpenWRT-based routers have the option of built-in DNS-based adblock, can thoroughly recommend the Turris routers for such things.

It’s worth noting that the ESS suite Chart is absolutely not built to be community-viable, it’s built for the kind of single-purpose deployments that Element offer hosting for, and it also breaks almost all Kubernetes best practices. Which is actually not wrong per-se. Element need to be able to maintain it after all, and since they don’t have the Kubernetes know-how to build generic components, it makes sense to instead bundle a fully integrated solution which they are comfortable with developing and debugging.

They’re definitely slowly but steadily rewriting Synapse in Rust as well, that’s been an open and ongoing project for a while now. You can see that just by looking in the Rust folder in the Synapse sources.
I strongly doubt that they have the “rest” of the application rewritten internally and keeping it hostage for paid hosting though, it’d cost them too much to keep separate codebases for such a thing.

The “Synapse Pro” offering is most likely just the regular Python+Rust Synapse, but with a few additional HA components and some workers written in Rust for efficiency, just like how there’s community workers written in both C# and Go for performance reasons.

If you don’t have a hard requirement for the Helm Chart to be written by Element themselves, I’ve been maintaining some Charts for Matrix components for almost six years - which have also ended up being used as the base for the German BundesMessenger project. Unfortunately free time hasn’t allowed me to do nearly as much as I want with it, especially since it continues to work for the use-cases for my job.

We do have a room on Matrix for dealing with Kubernetes setups though.

I also ended up chatting with one of the core devs of Synapse about ways to improve regular Python Synapse for use with Kubernetes back in the ending of January, so hopefully it’ll improve in that direction when time allows. They have the exact same problems with providing hosted setups after all, so they too want to make the open-source version easier to run.

One has super cow powers, the other one doesn’t.