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.
wakoinc / Blake
npub1kt…rmrvj
2023-04-08 08:05:33
in reply to nevent1q…ac60
Author Public Key
npub1ktw5qzt7f5ztrft0kwm9lsw34tef9xknplvy936ddzuepp6yf9dsjrmrvjPublished at
2023-04-08 08:05:33Event JSON
{
"id": "0820748d2e4b5c0d3bee7c7dd6b6765b23489d6d12a66831ea4a6392bbab2f7b",
"pubkey": "b2dd40097e4d04b1a56fb3b65fc1d1aaf2929ad30fd842c74d68b9908744495b",
"created_at": 1680941133,
"kind": 1,
"tags": [
[
"e",
"c2cc68ab7451b45392c6736714aab1ffefc213b932749d3d91b1ff00820d750f"
],
[
"p",
"7fa56f5d6962ab1e3cd424e758c3002b8665f7b0d8dcee9fe9e288d7751ac194"
]
],
"content": "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. \n\nPersonally 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. \n\nI 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. \n\nWe 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). \n\nAn obvious issue is also different language. Which to use in events, how to handle typos, and so on. \n\nAnd 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.",
"sig": "a182de2b8f1a3da6c692f9dbef5b1d35c9d72226f05ec892dbd981f3ad3c2e8bdf0d55fb6837737006fe3b3aa1dbb16d4b268d60a53576e80645838fce455f74"
}