let me just do you a favor re the Mastodon side of things, im not quite sure where you're going with the rest of the fediverse bit, but let me do a quick sum up of how to avoid even needing to talk about such features, and do it, mastodon side, with the features i have already laid out. i'll hit a couple notes on why these features need some sort of official support and implementation, some sort of standard, a bar to set the minimum a client should be doing.
when you are worried about the wider fediverse not properly federating and following the rules you are trying to set forth for say, content warnings, sensitive content and the like, i would like to put forward this example of things in general.
not everyone views the same things as sensitive
this is kind of easy to understand, i think, but adds to what i am about to try to sell to you.
so, if everyone does not have the same standards for what they need to be sensitive (an example is food needs a content warning for some people, but not everyone) is to implement the tool i have laid out at the top of this very thread. people need the ability to decide what they personally need warned about, need to be treated about as sensitive, and the like.
i understand this was decided to be too expensive on the server side in the other thread (https://discourse.joinmastodon.org/t/keyword-muting-for-anti-harassment-and-content-filtering/226/16) so let me answer how we should deal with this.
a few philosophies need to hold true here, and are things that are purely from the standpoint of the user comes first. we are, after all, creating a social media platform, ie, a place for users to exist.
something that has come up, and which, frankly, astonishes me that was treated as it has been, is the example of different clients not sharing information. this is very simple to fix, we just need, server side, to create the UI to store settings, to set the standard for how these settings should be handled, the level of granularity that needs to be dealt with, so the user does not need to set those same settings multiple times
let me rephrase, as i am getting into jargon and fancy talk about users and experience.
put simply: the philosophy of every individual client to use mastodon with, using THE SAME ACCOUNT, to not share such a simple, central setting as the default posting level of publicity, is absurd. this same philosophy is carried over to muting, to dynamic content warnings, and are simply against the user in terms of usability.
let's say i personally have a STRONG aversion to food. i do not, but this is an example, and is a thing that is semi-frequent.
i am a user, i sign up for mastodon, and i get some users followed and such. so, early on, i encounter a image of muffins, tagged "food" by the user, but not behind a content warning. i propose that this become the default in many cases, so that for things that are considered to be generally acceptable for public viewing can be publically viewable without the annoying content warning button. then every user could set a setting to add a content warning, to hide that image, so they dont get sick due to the food.
so now i decide i like mastodon, and i go to get a mobile app.
not only am i accidentally posting to the public timeline ALL OVER AGAIN, but i am now finding myself seeing food i really wasn't expecting, coz like, i muted it already, right? and that only makes seeing the thing i chose to not want to see EVEN WORSE.
this is a thing @Gargron has said will not be stored serverside but i would argue is vitally necessary. please, please listen to me when i say this, and at the very least, create the UI proposed, and set the example for allowing users to properly hide content as makes sense.
back to the topic of this thread and the other, this keyword muting-behind-a-content warning feature being combined with images being hidden being amalgamated into the content warning feature to require a tag means that the UI is much clearer and the user experience is overall so much better.
now that i (hopefully) have changed someones mind, or at least convinced people of why these things are being handled very badly as is, i hope people will listen to me.
i will happily outline a very comprehensive github feature as @maloki suggested, but i am really not up to defending my case again and again, as i have. that is the number one reason i have tuned out of this conversation so long, the only people who do not want these features to change, that i can tell, are people who are eventually convinced that my way is correct! as such, i will happily do these conversations on a person-by-person basis but i'm really tired of reiterating what has already been said. please read the entire thread before stating that this feature should not exist, or that it is losing granularity. please read it all, i know it's a lot.