A limitation today is clients not being easily able to tag a new event with a content-warning. Could be due to App Store approval concerns. I’d start understanding that first.

Personally I think in depth pre-defined tags are the wrong approach. Net nanny and FWs use them, and it’s often inaccurate (e.g. lots of false gambling flags) - it encourages opinionated blacklists. My only exception is what would normally be under NSFL - almost always watching death occur.

I see normal hashtags as being flexible enough if you want some descriptors for searching or knowing what to expect before you un-blur media content. Explicit websites seem to just list tags. And Nostr events can be tagged without hashtags in content.

We are missing an explicit key in the kind0/profile metadata today. A profile image or banned could be explicit - not just their events. I think that’s easy to add - just add content-warning to the kind0 json. An edge case is showing an event before a profile event first loaded - you could see an explicit profile icon, if the event is not tagged (if it is tagged, and profile isn’t known, it could just blur by default).

An obvious issue is also different language. Which to use in events, how to handle typos, and so on.

And as always, it’s best effort as we have no guarantee the publisher will tag or use some pre-defined list. Reporting can be abused for censorship. For open networks I advocate better client filtering tools - rather than protocol level rules.