It also further links to another issue about individually blocking users and communities. Apparently that is quite inefficient in the current version, so maybe that adds to your problem?

What you can try is to clear your browser cache for the main domain. In the past there was a bug in Lemmy that caused Firefox based browsers to accumulate many gigabytes of cache data and that slowed down the loading of the page significantly. In the latest version there are some fixes for this and it shouldn’t effect app usage, but I suspect this problem still persists to some extend.

Aside from general issues others have mentioned, our instance (slrpnk.net) is seeing some especially high database load in the last couple of days and I also noticed the subscribed page to be even slower than usual. I tried to figure out what it causing it, but so far there is no clear smoking gun, but I suspect some AI scrapers found a way to target the Lemmy API directly so our current scraper protections for the webinterface are inadequate.

Indeed, Postgres 18 introduced some breaking changes and AFAIK Lemmy isn’t compatible with them yet. This will probably be fixed in the next release.

Afaik it is a specific implementation issue in Lemmy that causes this. Instances in Australia had problems catching up with lemmy.world because of that.

It probably has less to do with Qatar and more with US arms producers wanting to sell fighter jets and drones to Qatar.

1 . As you could have guessed from the community this was posted in, a software that is part of the fediverse. It has various modules for different functionality. 2. Because they made a long blogpost that explains the new features that you hopefully read before commenting?

MAU is a very incomplete measure of active users as by far the most users lurk and post very little.

In total numbers Mastodon has about 10m users and only 30% of those are on mastodon.social, the rest is distributed on the 9k other instances. That’s pretty close to the scenario you stated.

So lets say there are 100 instances. My instance needs to issue api requests to each instance to sync with the network. They in turn need to issues 100 requests to me to sync (and eachother). What about when there are 100k instances? Its exponential.

This falsely assumes that everything gets federated to everyone, which isn’t the case for ActivityPub. You only get what you actually subscribe to with it.

Mastodon already has those numbers you mention and there are no performance issues in the overall network.

Modern webservers don’t have a problem serving thousands of requests as long as they are spaced out a bit timewise. And since each AP instance only sees and interacts with a small part of the overall network it should not become an issue to expand the network horizontally. It is anyways probably better to think of interconected archipelagos and not of a singular network in the case of ActivityPub.

ActivityPub is designed to scale well for millions of users with a low number of subscribers each (Dunbars number and so on). It is not designed as a mass media publishing tool where a few have tens of thousands or even millions of followers.

I consider this a feature, but feel free to disagree.

This depends on what you think the purpose of ActivityPub is and subsequently the type of scale. ActivityPub is designed for horizontal scale in a “social network”. If you have lots of participating entities with a more or less similar number of interconnected subscriptions ActivityPub scales extremely well, unlike ATProto, which needs to more or less ingest the entire network in its firehose.

But you are right that ATProto is better designed for “social media”, meaning that most subscriptions are one sided affairs with highly visible “influencers” being the main point around which the network operates. Obviously this is what most commercial networks are more interested in as it allows profitable advertisement and other forms of social influence.

I see these two types as entirely different forms of social interaction, and couldn’t care less about the latter. So I am not worried at all about scaling issues of ActivityPub, as it scales extremely well in the “social network” type of interaction.

Hmm, afaik other than some generated small thumbnails no remotely sourced images are stored on your server when you turn off the proxy. At least in theory, but the entire Pictrs integration in Lemmy is such a mess with random unexpected behavior that at this point I am hesitant to claim that no remote images ever get stored (there seem to be alternative code paths for specific image hosts like Imgur and crap like that).

The main issue with hosting your own fediverse instance is that federation doesn’t happen by itself and you need to quite actively search for accounts to subscribe to so that the servers start talking to each other.

I am not sure OP is asking about hosting a Lemmy instance though. They mention non-Lemmy fediverse software.

However I think you misunderstood how proxying works:

Note that this has been drastically reduced with the image proxying, where if someone on say, .world posts CSAM it’s proxied through my server but not hosted by my server. So, liability is still a thing, but as long as the admins of .world take action then i’m protected with them. If proxying is disabled then the CSAM would live on my server too - and that means I’m legally required to report it.

It is actually pretty much the oposite of what you describe. The image proxy in Lemmy is a user privacy feature, but it comes with the downside that the server does indeed download and temporarily stores all media that are requested through it.

“Somehow”… seems to be caused by using centralized MitM Clownflare that supposedly protects against DDOS 🙄

Sounds like such unscoped requests should not be allowed in the first place? Maybe worth reporting in a Lemmy issue?

Matrix Synapse is AGPL, and it is very much open-core these days, see Synapse Pro.

This is IMHO the main risk, at some point someone might say, why not give our hosting an small advantage over others, and it is all downhill from there.

The feddit.org server is in Austria. But that doesn’t make any difference when (some of) the admins live in Germany. They could still get their homes raided by police.