@Comrade Ferret The fediverse has a whole mix of protocols, not all of which are congruent, so even before you get into local system policies you have the issue of protocol incompatibilities. Therefore you might want to think about what you say before you say it because more likely than not it will be as permanent as the fediverse.

@Comrade Ferret Mastodon is only ONE player in the fediverse, I have a Mastodon instance (mastodon.eskimo.com) but also a Hubzilla (hubzilla.eskimo.com), and a Friendica (friendica.eskimo.com), and a Pixelfed (pixelfed.eskimo.com), and a Nextcloud (nextcloud.eskimo.com), and a Yacy (yacy.eskimo.com), although there is overlap in the protocols and some speak multiple, Friendica for example is not obligated to obey Mastodon's API or Mastodon Friendica's. It is good to the extent that they do because it is what makes the fediverse work at all, but usually one servers implementation of another's protocol is not 100%. It is good for delete's to function, else how to you limit spammers and the like, but you should not anticipate it to be a guarantee. Sites that fail to honor it, well they are going to get more than their fair share of spam.

@Comrade Ferret I don't think it is baked into the protocol of these servers but there are literally hundreds on the fediverse and there is also the potential of local hacks given that these are all open source but I think a more frequent problem is not deliberately ignoring such requests but rather incomplete protocol implementations and servers running on inadequate platform that are dropping 9/10ths of what comes in for lack of adequate resources to keep up. As an example when I first turned up my friendica instance, the database was on rotary hard drives and maxed out at about 300 tp/s, and it was consistently backed up. Now I'm running it on an 18 core/36 thread machine with 256GB of RAM and database is on RAID-1 nvme array and is capable of more than 10,000 tp/s, averaging about 1700 tp/s. People start these without any idea of the resources required. I have no doubt mine in it's infancy dropped a lot of requests. I think the bottom line is that the fediverse is not a high-reliability network in terms of individual nodes, it's main claim to fame is that by being distributed it is censorship resistant. In my view that is a VERY worthwhile objective and the reason I run so many services.

@Comrade Ferret There are various buffers and cache in mariadb, the most important of which is probably innodb_buffer_pool_size, I have mine set to 80G. Ideally you want this to be as large as all of your databases if you can afford the RAM because this way your server will mainly operate out of RAM which is infinitely faster than even nvme. And friendica's database load is 92-93% read and only 7-8% write so it benefits massively from cache. Others that are important particularly for friendica are join_buffer_size and sort_buffer_size because friendica does a lot of complex joins and if these aren't large enough external file system tables are used. With them both set to 256M I get about 3% overflow to files. On my system this is not expensive because the /tmp directory where it creates these overflow tables is a tmpfs memory file system, if yours is not it will benefit even more from adequate sized buffers here. And table_open_cache ideally will be large enough to accommodate all of the database tables in your database because open is a relatively expensive operation. Another is table definition cache, again as many tables as you have. query_cache_limit, here you are advised to keep under 64M because if larger it may take longer to search the cache however locally I found this to be untrue and for my server at least 38M is the sweet spot, but again I can get away with this because the machine has 256G of RAM, this particular item is a per client item, so whatever you set it to multiply that by the number of clients you allow to determine the max memory it will eat. At this point I have roughly 4 slow queries per 10,000,000 queries with a query rate of 1700 tp/s on average.