NIP-68 & NIP-69 - defined vocabulary for content warning & reporting (NIP-36 and NIP-56)

[rabble]

This NIP defines a vocabulary and spec for content that users tag with NIP-36 (Content Warning) and NIP-56 (Content Reporting).

To understand why we need this and how it'll be used: https://s3x.social/nostr-content-moderation

This spec was primarily created by: S3X-Jay npub1veeqt66jt2j209y9nv4a90w3dej074lavqygq5q0c57dharkgw0qk738wt with some input by myself and others.

As stated, this is about a set of public standards for tagging and categorizing content that some users and relays may want to publish and see, or not host or see. Like with all NIP's the implementation is optional and up to the relay and clients.

[olheadinternet]

just don’t use the touchy issue term.

46 PR-frd - Promotion of content that is likely to cause financial ruin (consider also IL-frd)

47 PR-hr - Promotion of content that is likely to cause serious bodily harm or death

120 PR-frd and PR-hr is only supported for "Your money or your life" situations - where serious harm can come to the user.

---

Avoids blame and projecting low expectations:

118 Intolerance & Hate (IH) is clearly in the eye of the beholder and it's likely that it will be ignored by the majority of relays. 
Reports on intolerance and hate are included to maximize choices for individuals and individual relays.

---

maybe a nn - non-nude for a “particular parts” self report that’s trying to communicate that it’s, for lack of a better term, “an instagram” of an adult performer? Porn-related content is not erotica literature or porn.

[mikedilger]

I abhor globally defined vocabularies, because they are always wrong somehow. As an example, just in the first six, all six of them are debatable and jurisdiction dependent (for brevity and to avoid a flame war I won't demonstrate by example).

I think the problem of unwanted content should be attacked in a more bottom-up way, which is to say I don't think the nostr protocol should define such a vocabulary.

If I want to avoid certain content (e.g. inaccurate usage of the word "literally", or woke usage of the term "gender" because that always infuriates me unnecessarily) and I also trust someone to tag/report such content accurately, then I will subscribe to their vocabulary which probably won't have much in common with this PRs vocabulary. That is to say, the vocab needs to be defined between the producer and the consumer, but not globally.

EDIT: I'm not going to further comment in this thread. I'll opt out of this stuff.

[s3x-jay]

Mike - I hear you and I get your concern but this is a vocabulary intended and designed for “bottom up” use. The moderation requirements to run a relay in North America or the EU are huge. They’ll be cost prohibitive. And without US/EU compliance you don’t have Damus and other iOS apps.

One of the primary objectives of this is to let relay owners share the load of moderation duties with other relays and end-users they trust. (This is just the first step in that process). To do that you need a common vocabulary. The items on the list are just the big obvious targets for US/EU compliance and the items that are likely to be important to “communities of interest”.

I think you can see that two people can report completely different posts with the same code. That’s the whole point. Each community can filter based on its own standards. You trust moderators A,B,C and I trust moderators X,Y,Z. Just because you report something doesn’t mean I will act on your report. It just means people who agree with you will act on your report. That’s what bottom up content moderation looks like. The vocabulary is just a way for those people to communicate.

[rabble]

One of the issues we're trying to tackle is avoiding the mistake of ActivityPub. Take Mastodon for example: https://docs.joinmastodon.org/entities/Report/

Their content reporting system has three categories:

• spam = Unwanted or repetitive content
• violation = A specific rule was violated
• other = Some other reason

We know that the current vocabulary is not perfect, it'll need to be expanded and updated over time. And yes there are jurisdictional issues, things that are legal in one country like insulting the king or prostitution are illegal in another. But we empower relay operators, client developers, and ultimately users to make informed choices easily if we provide these categories.

I want to be able to legally allow users under the age of 18 use Nos. But in order to do that, I need to make sure the app complies with a different set of regulation than adults.

@mikedilger, giving a categorization system and letting relays, apps, and users decide is the bottom up solution. It avoids blocklist / ban lists and a centralized system that defines a single set of rules for Nostr. Or more likely, a single set of users for all the nostr apps installed via appstores. Your app doesn't run on mobile devices and you can ignore all these messages in your app. Almost all NIP's are optional.
The other thing you're talking about are word filters, which aren't so much a protocol level feature as an app.

[mikedilger]

I wasn't going to comment, but so many things come to mind that affect compliance and law that are not in your list that I had to get them out of my head. So here.

• Holocaust denial (Germany)
• Imagery of Mohammad (Islamic nations)
• Libel (nations based on English common law)
• Content that promotes Racial Disharmony (NZ HR Act 1993 section 61)
• Classified, Secret or Top Secret content
• Violation of an NDA
• Disclosure of troop movements during a time of war
• Perversion of the course of justice (quash orders, name supression, jury tampering, etc)
• Incitement of violence

and of course let's not forget

• Inadvertent nipple slips of pregnant adult females sitting on chairs with straight black hair
  (c'mon, you thought that was funny)

Gossip client will provide a mechanism where people can plug in their own content filters, either as Lua code, or gRPC to a server, or something else, and if they wish they could use your vocab. But gossip will not be involved in these nitty-gritties other than that.

[s3x-jay]

@mikedilger - The "IL" category is the catch all for "unspecified illegal content" and could be used for all the cases in your list. Unless there's something really huge that's missing, I would suggest waiting for the input of moderators who regularly work with NIP-56 reports. They'll know what unclassified types are frequent enough to warrant a specified sub-type. A full list of every crime in the world would be rather bad UX!

And "Inadvertent nipple slips of pregnant adult females sitting on chairs with straight black hair" is covered by "NS-nud". ;) But that brings up another issue - "severity". Clearly a accidental nipple slip is not the same as being at a nude beach, but both are covered by NS-nud. Severity could be something we add to NIP-56 reports, but it seems like overkill for end users - it's more of a tool for actual "moderators". We need to keep it relatively simple for end users.

The "plug in your own content filter" will be covered in a subsequent PR. It's coming. Very briefly, my idea for that is that people will have "trust lists" that work much the same way as "follow lists" and "block lists" - only for content filtering. That lets the user specify whose NIP-56 reports are used and possibly in what context. Of course the same thing can be achieved in other ways. That's all up for discussion. This NIP simply defines the vocabulary for whatever solution moves forward.

[fiatjaf]

Who is supposed to write these content warnings? The user, when posting some nudity, will have to pick a category from a huge dropdown?

[Giszmo]

Suggested change

	Self-reporting a post...
	{
	"pubkey": "<pub-key>",
	"created_at": 1000000000,
	"kind": 1,
	"tags": [
	["t", "hastag"],
	["content-warning", "Wet t-shirt contest", ""NS-ero"]
	],
	"content": "(Racy content goes here)",
	"id": "<event-id>"
	}
	3rd party reporting of same post...
	{
	"kind": 1984,
	"tags": [
	[ "e", <eventId>, "NS-ero"],
	[ "p", <pubkey>]
	],
	"content": "Wet t-shirt contest",
	...
	}
	Self-reporting of an entire profile...
	{
	"id": "<event-id>"
	"pubkey": "<pub-key>",
	"created_at": 1000000000,
	"kind": 0,
	"tags": [
	["t", "hastag"],
	["content-warning", "Posts frequently feature drawings of naked people.", "NS-nud,FA"]
	],
	"content": "{\"name\":\"OttawaLifeDrawing\",\"about\":\"Ottawa's newest life drawing classes!\"}",
	...
	}
	3rd party reporting of same profile...
	{
	"kind": 1984,
	"tags": [
	[ "p", <pubkey>, "NS-nud,FA"]
	],
	"content": "Lots of drawings of nude people",
	...
	}
	Self-reporting of particular parts of a profile...
	{
	"id": "<event-id>"
	"pubkey": "<pub-key>",
	"created_at": 1000000000,
	"kind": 0,
	"tags": [
	["t", "hastag"],
	["content-warning", "I'm a trans pornstar. My avatar is G-rated, but the header pic is a bit racy. My website link goes to a porn site and most of my posts are porn-related.", "PN-trn,PN-trn-website,NS-ero-banner"]
	],
	"content": "{\"name\":\"PollyPornstar\",\"about\":\"Award-winning trans pornstar\",\"banner\":\"https://somesite.com/somepic.jpg\",\"website\":\"https://pornsite.com\",\"picture\":\"https://somesite.com/anotherpic.jpg\"}",
	...
	}
	3rd party reporting of the same parts of the same profile...
	{
	"kind": 1984,
	"tags": [
	[ "p", <pubkey>, "PN-trn,PN-trn-website,NS-ero-banner"]
	],
	"content": "Trans pornstar with racy banner and website link to a porn site.",
	...
	}
	Self-reporting a post:
	```
	{
	"pubkey": <pubkey>,
	"kind": 1,
	"tags": [
	["t", "hashtag"],
	["content-warning", "Wet t-shirt contest", "NS-ero"]
	],
	"content": "(Racy content goes here)",
	"id": <eventId>
	}
	```
	3rd party reporting of same post:
	```
	{
	"kind": 1984,
	"tags": [
	[ "e", <eventId>, "NS-ero"],
	[ "p", <pubkey>]
	],
	"content": "Wet t-shirt contest",
	...
	}
	```
	Self-reporting of an entire profile:
	```
	{
	"id": <eventId>,
	"pubkey": <pubkey>,
	"created_at": 1000000000,
	"kind": 0,
	"tags": [
	["t", "hashtag"],
	["content-warning", "Posts frequently feature drawings of naked people.", "NS-nud,FA"]
	],
	"content": "{\"name\":\"OttawaLifeDrawing\",\"about\":\"Ottawa's newest life drawing classes!\"}",
	…
	}
	```
	3rd party reporting of same profile:
	```
	{
	"kind": 1984,
	"tags": [
	[ "p", <pubkey>, "NS-nud,FA"]
	],
	"content": "Lots of drawings of nude people",
	…
	}
	```
	Self-reporting of particular parts of a profile:
	```
	{
	"id": <eventId>,
	"pubkey": <pubkey>,
	"created_at": 1000000000,
	"kind": 0,
	"tags": [
	["t", "hastag"],
	["content-warning", "I'm a trans pornstar. My avatar is G-rated, but the header pic is a bit racy. My website link goes to a porn site and most of my posts are porn-related.", "PN-trn,PN-trn-website,NS-ero-banner"]
	],
	"content": "{\"name\":\"PollyPornstar\",\"about\":\"Award-winning trans pornstar\",\"banner\":\"https://somesite.com/somepic.jpg\",\"website\":\"https://pornsite.com\",\"picture\":\"https://somesite.com/anotherpic.jpg\"}",
	…
	}
	```
	3rd party reporting of the same parts of the same profile:
	```
	{
	"kind": 1984,
	"tags": [
	[ "p", <pubkey>, "PN-trn,PN-trn-website,NS-ero-banner"]
	],
	"content": "Trans pornstar with racy banner and website link to a porn site.",
	...
	}
	```

[s3x-jay]

Who is supposed to write these content warnings? The user, when posting some nudity, will have to pick a category from a huge dropdown?

Huge drop down? The way I see it working (client app developer can implement it differently if they choose) is first you present the main categories to the user:

• Coarse Language / Profanity
• Illegal
• Intolerance & Hate
• Likely to cause financial ruin
• Likely to cause serious bodily harm
• Nudity & Sex
• Pornography
• Spam
• Violence

Not every category has to be presented to the user. For example I left out the "No sensitive content" option because it should only really be presented if the user has labeled something about their profile as sensitive and there's an assumption of sensitive content. I would also suggest we merge "impersonation" into "identity theft / phishing".

In the case of nudity which you mention, the person would pick "Nudity & Sex" and then either stop (at which point the code over the wire is "NS"), or they're shown the three sub-categories and they pick one of those if they want to be more specific…

• Casual Nudity
• Erotica
• Sex

Optionally the person could specify a context from the list of 6 contexts. (e.g. it's nudity, but it's in a scientific/medical context). But contexts should be presented separately. They're important when they apply, but will only be used by a small subset of users.

So at most to specify a content warning of nudity it's a matter of picking something from a list of 9, then optionally picking a subcategory from a list of 3, and possibly specifying a context. UX experts say the optimal number of items in a list is 5 to 9, so we should be fine.

And a client app could alternately show recent or frequent report types so they can be chosen with a single click.

[michaelhall923]

I believe this is good-intentioned, but in practice it only serves to control and limit language. It's an attempt to turn gray areas into black and white.

[staab]

I sympathize more with the people who don't want this than with those who do, but given how important it is for some operators (myself included) to be able to implement this behavior, I think we should push forward on getting this merged. The neat thing about Nostr is that pretty much the entire protocol is optional, so if someone wants to ignore this NIP, they're free to do that. Nostr can't even censor itself!

[staab]

Who is supposed to write these content warnings? The user, when posting some nudity, will have to pick a category from a huge dropdown?

Personally, I think the content warning use case will apply to such a vanishingly small set of good-faith actors posting iffy content as to be basically useless, but it's worth allowing them to do so. The more important use case in my mind is for reporting.

[michaelhall923]

I think we should push forward on getting this merged

I wouldn't be so hasty. This NIP cuts to the core of the reason nostr was created to begin with. If not implemented properly, this kind of thing could literally kill the protocol.

[s3x-jay]

Have you guys seen PR 459? Personally I like how it reframes this entire discussion in terms of "labeling" rather than "reporting" and "content warning". I think that captures what the core of what NIP 69 is trying to do - it's just about defining a set of frequently used labels.

But I don't think changing the name to labeling eliminates the need for a defined vocabulary. We could say that people can use whatever labels they find useful, but the NIP 69 defined vocabulary are the ones relay moderators and others find useful enough to regularly monitor and take action on (as needed/desired).

Personally, I think the content warning use case will apply to such a vanishingly small set of good-faith actors posting iffy content as to be basically useless, but it's worth allowing them to do so. The more important use case in my mind is for reporting.

Yes, people who send truly iffy content don't tell you it's iffy (e.g. no spammers put [spam] in the title of their emails).

That said, NIP-36 is about more than "iffy" content. I think the legit porn industry would use NIP-36 pretty consistently. Definitely on automated events, and I think many would use it on events they send manually IF the client they're using lets them specify default values. Porn professionals have zero interest in minors and people who don't like porn seeing our content - those people don't buy anything. (Not to mention the legal issues with minors.)

That said there is overlap in NIP-36 and NIP-56. NIP-36 could be deleted and replaced with self-reporting via NIP-56. The only downside would be that the content type designation / "label" wouldn't be in the note itself. It would need to be retrieved by looking for a related kind 1984.

I wouldn't be so hasty. This NIP cuts to the core of the reason nostr was created to begin with. If not implemented properly, this kind of thing could literally kill the protocol.

Can you specifically describe a scenario where this could kill the protocol? From my point of view not doing this will kill the protocol because all the major relay owners will wind up in court. So I'd like to understand your point of view better.

…given how important it is for some operators (myself included) to be able to implement this behavior, I think we should push forward on getting this merged.

The amount of trouble you can get into by hosting/transmitting/displaying "problem content" (of all sorts - not just porn) is huge. Those of us in the porn industry want proper content moderation because we've had these legal clouds hanging over us for years. Making a good faith effort to do the right thing does count for something if you wind up in court. Ignoring the problem and hoping you're not the one who gets sued or charged with a crime isn't a good business strategy.

[mikedilger]

I think we should push forward on getting this merged

I wouldn't be so hasty. This NIP cuts to the core of the reason nostr was created to begin with. If not implemented properly, this kind of thing could literally kill the protocol.

There are many relays. Some will censor lots, some will censor only a little; some will censor pornography, others will only censor illegal content; some will use these reports, some wont; nostr cannot and will not be killed. Even if 99% of people use highly censorious relays, me and my tribe will continue to speak freely onto relays in places like Russia if necessary so that they won't be taken down. It already cannot be stopped outside of big-government Internet backbone type actions.

I hate defined vocabs as I mentioned already, but I understand why relay operators need something like this.

I guess I'm just surprised at how many sexually-related categories there are, and how few illegal categories there are, given that I would presume that blocking illegal content would be super-duper important for relay operators, and filtering to find only posts that satisfy your kink seems massively less important.

[s3x-jay]

Mike - thanks for your support!

I guess I'm just surprised at how many sexually-related categories there are, and how few illegal categories there are, given that I would presume that blocking illegal content would be super-duper important for relay operators, and filtering to find only posts that satisfy your kink seems massively less important.

In terms of "why so few illegal categories?" - it's because the UI would get overwhelming if there were more. UX standards say that you should have a max of 7 items in a drop down (±2 - so a range of 5 to 9). There are 8 subcategories of illegal - so at most we'd want to add one more. Can you think of categories that are more likely to be problems than the ones listed? Which ones are on the list is completely open to discussion. I just did a little bit of light research on what were the most common illegal activities on the web and chose those.

In terms of "why so many sexually-related categories there are compared to illegal?" - there are 3 sub-categories under Nudity & Sex and 6 under Porn - so a total of 9 - just one more than illegal. Nudity & Sex is separated from Porn because there's a substantive difference between the two. For example both mainstream films and porn may contain similar erotic scenes - but one is meant to "stimulate" the user, the other is just part of a generally non-sexual plot line. In terms of "why are there so many categories under Porn?" - that's because if a person is bothering to report something for being porn they're likely to have very strong feelings about which type of sexuality is portrayed. (Sadly, sexuality and porn has been politicized a lot lately.)

[michaelhall923]

My feeling is still that a defined vocabulary doesn't belong in the NIPs. Not to say that you shouldn't use a defined vocabulary, just that it's something relay operators should coordinate outside of the NIPs. That would also make it more flexible and easy to change if needed since it wouldn't be baked into the protocol.

[s3x-jay]

My feeling is still that a defined vocabulary doesn't belong in the NIPs. Not to say that you shouldn't use a defined vocabulary, just that it's something relay operators should coordinate outside of the NIPs. That would also make it more flexible and easy to change if needed since it wouldn't be baked into the protocol.

If it's not defined in the NIPs how does everyone get on the same page and use the same vocabulary? All the major client apps need to implement it or else it's not going to be of much use. If different clients use different vocabularies then you might as well not have a vocabulary. This only works if everyone is on the same page and the NIPs are what people on the same page.

And I should mention this isn't the end of what's needed for content moderation. It's just an essential first step in a much bigger vision. My goal (and I think Rabble's goal) is to have a system where there's a cacophony of voices giving input on what should be moderated. There can be individuals, organizations, corporations, governments, professional relay moderators, and so on. Then the user picks which of those voices they want to have a voice in moderating/filtering their feed. It's a bottom-up approach - not top-down.

Likewise, relay owners would pick which of those voices they can trust enough to take automated action based on their input. So for example there may be a bot that analyzes images and matches them against known CSAM. I could set things up so if they report something and I find it on my server I don't even have to look at it to take it down - I trust them enough to delete without question.

But for all of that to work everyone has to use the same vocabulary. Particular groups can extend that vocabulary for particular use cases, but there needs to be a starting point that everyone agrees on. [Thinking about that - defining how to extend the vocabulary is something that should probably be in this NIP.]

[olheadinternet]

so i'm not sure how strict this has been but just from sequential pov

Criteria for acceptance of NIPs:

1. They should be implemented in at least two clients and one relay

a) you're probably going to need to build a client that can generate the tags
b) and you're probably going to want to build a not just a relay, but relay software that assists in managing these as relay operator

IMO nips are for where the tag goes, not what goes in the tag.

I think you can build out the lexicon (of what goes in the tag) outside of the relay implementation, so if someone wanted to come and use that lexicon with in a different relay implementation in a different coding language, they would be free to do so and not feel like they were building with your relay implementation. I hope that's done in a similar open way, maybe with it's own Criteria for acceptance, so both members who are vehemently pro/con the basic idea here, or might not turn the filters on, can still contribute to the language. This also might allow your lexicon to be more open to be used in bridging, where as a nip, it would feel like to them that it was an implementation of nostr on the bridged protocol, which isn't going to be welcomed to their protocol die hards. Where a independent vocabulary isn't going to be so hostile towards either other protocols or other devs building competing relay implementations.

the next sequential step is a & b above, not "pushing forward on merging" that does seem very hostile.

[mikedilger]

I think it makes sense for things that require all the different parties to be on the same page to be specified in a NIP. Well-known content of tags falls in that category. We did that for lots of stuff already like in NIP-11.

[michaelhall923]

People find a way when a need arises. The defined vocabulary should arise organically over time. Not chosen by a handful of benevolent dictators.

[s3x-jay]

so i'm not sure how strict this has been but just from sequential pov

Criteria for acceptance of NIPs:

1. They should be implemented in at least two clients and one relay

a) you're probably going to need to build a client that can generate the tags b) and you're probably going to want to build a not just a relay, but relay software that assists in managing these as relay operator

Rabble & I are aware of those criteria - it's one of the reasons why this PR hasn't been approved yet. We're both busy and I'm still getting up to speed on Nostr development.

I think it makes sense for things that require all the different parties to be on the same page to be specified in a NIP. Well-known content of tags falls in that category. We did that for lots of stuff already like in NIP-11.

Right, and this comes out of an inadequate vocabulary being specified in NIP-56.

[s3x-jay]

People find a way when a need arises. The defined vocabulary should arise organically over time. Not chosen by a handful of benevolent dictators.

Michael - this IS the organic process… And it's organic on several levels…

I'm a total outsider - not a benevolent dictator. I didn't even have a GitHub account a few months ago. I'm so bad at Git that Rabble had to post my PR for me, and I've completely f'cked up my attempts to edit the document.

And it's organic in the sense that it's involving the input of multiple external communities. The LGBT community, the porn community, the fetish community, and people with experience running both large and small social media sites. What you don't see is that behind the few of us who are here are all the people we're talking to and getting input from behind-the-scenes - people who often don't have GitHub accounts…

And it's not a coincidence that this PR was posted by two people from the LGBTQ community. Just yesterday I got my first, not-so-subtle death threat on Nostr. I did a post saying "Our sex-positive, porn-friendly, gay-owned and operated relay is FINALLY up and running" and got multiple responses from someone - a couple were cartoons - one of which had someone bashing a gay person's head in, and yet another of their responses said "Kill all child groomers" and had a pic of people being hanged. (note1f76fad06wvcre5zaqu6xm4vdyyk0f5jycegrgyes03hgtyndq0hqs738lk) So, to recap, the first (AFAIK) LGBT relay gets launched and that's the response. The ability to moderate content matters to the LGBTQ community in a way it doesn't matter to other people. I wish that weren't the case, but it is and it explains why we're the ones leading the charge on this issue.

I've heard one or two of personal the experiences which are behind why content moderation matters to Rabble - I'll let them tell their own stories. I have many stories - but typical is a story I heard this week… A friend works at the UN and is sometimes in conflict zones. One of his gay colleagues got kidnapped in a conflict zone and his friends and family started freaking out - worried that if the kidnappers figured out he was gay it would turn from a ransom situation to him being tortured and possibly killed. They had to frantically contact all of his friends and family and beg them not to post anything on social media that would indicate he was gay, and to delete anything they had posted in the past that mentioned his sexuality. Social media can be a unifying force for the LGBTQ community, but there are also times when it can lead to our death. It's why we view these things differently than you do.

The point being the voices here who asking for proper content moderation aren't benevolent dictators - we are the representatives of end user communities and we're spelling out what we need. This literally is the organic feedback you're talking about. And this is the right time to put something in place.

AND… the people who have experience doing content moderation think what we're proposing makes sense…

Yesterday I had the sense you didn't see the big picture I had in my head, so I wrote up this rather long document trying to give the general sense of how I saw content moderation working on Nostr. I didn't mention it here because it felt like a rough draft. But I shared it with Rabble and he shared it with his contacts on Twitter and Mastodon - what I wrote - please read it , and the response Rabble got on Mastodon. Notice the comment from Yoel Roth - who was head of Trust & Safety at Twitter until Elon took over - "The taxonomy here is great. And broadly, this approach seems like the most viable option for the future of moderation (to me anyway). Feels like the missing bit is commercial: moderation has to get funded somewhere…"

I'm not sure how much more of an organic process you need. You have people from end-user communities proposing something that's experts in content moderation think is a good, workable plan…

Hopefully, as soon as we can get a demo app up and running this can move forward.

[blakejakopovic]

For completeness, I shared detailed feedback previously, and alternative approach ideas in #315 (comment). TLDR: NACK on this fine-grained categorisation approach - we can make generic sensitive-content far better, without directly seeding censorship primitives. Unsubscribing thread again, as I see common sense prevailing here, and I've shared what I have for now.

[staab]

I had a pretty revealing conversation this week with @s3x-jay on the topic of "hate speech". The term is an Orwellian nightmare designed to suppress political speech by associating it with criminal or threatening speech. This is what many people came to Nostr to escape from. Yes, people can ignore the tag if they prefer, but including it in the protocol is an implicit endorsement of the concept, which is extremely dangerous to the concept of free speech.

The UN defines hate speech this way:

any kind of communication in speech, writing or behaviour, that attacks or uses pejorative or discriminatory language with reference to a person or a group on the basis of who they are, in other words, based on their religion, ethnicity, nationality, race, colour, descent, gender or other identity factor.

This is an overly broad definition, and can include anything from death threats, to a pastor reading the literal words of the Bible, to any word that might be taken as racist (e.g. "whitelist", "master branch").

For this reason, I strongly oppose this NIP unless the "IH" category is removed. The fact that it's "standard" does not help anything, we all know the world has lost its mind and its standards mean nothing. Other terms could be substituted, including "inappropriate" to indicate arbitrary subjective distaste, "threat", "racism" and others.

[michaelhall923]

Let's say I'm morally opposed to people wearing bananas on their head. Should a designation for that be added to NIP-69? No? Why not? You don't think that that's a significant enough category? Why is "Coarse Language / Profanity" a valid category but "Banana Hats" isn't? That's you making a moral judgment on the PROTOCOL level. This is a line we don't want to cross. This NIP should be scraped entirely.

[s3x-jay]

I had a pretty revealing conversation this week with @s3x-jay on the topic of "hate speech". The term is an Orwellian nightmare designed to suppress political speech by associating it with criminal or threatening speech.

Those of you who haven't seen it, please read the full conversation in the link. In it @staab starts by trying to police how I express my concerns (which are typical of the concerns of my community). Then he goes as far as saying that an explicit death threat against my community and possibly me in particular isn't hate speech. That is the context here. We then got into the fact that a community which he self-identifies with (Christian conservatives) are directly actively attacking both the LGBT community and the porn industry (both of which I represent).

I'm sorry, but I find it a bit rich that someone who tries to police my self-expression is trying to take the high ground on the basis of free speech. Perhaps he should start by not trying to tell others what words they're allowed to use.

If you read the NIP, you'll see the the same category/term can be used from different perspectives. In fact it can be used to completely opposite objectives, but it works because users pick their own moderators - moderators who think like they do. So "hate speech" (or any of the other categories) can't really be misused. It will never suppress content that the user wants to see because the labeling reflects the end user's way of thinking.

Hate is, sadly, a fact of life that's felt by many types of groups - including conservative Christians. It's something that's necessary to include so that many different types of communities feel safe on Nostr. And the UN's broad definition is because hate manifests itself in so many ways and means different things to different people. So the "hate speech" category will get used contextually.

TechCrunch recently did an article entitled "For Bluesky to thrive, it needs sex workers and Black Twitter". I would say the same is true for Nostr. Both of those groups need to protect their communities from hate.

I once heard it said "if you're against same-sex marriage don't marry someone of the same sex". Same is true here. If you're against labeling things as "hate speech" then don't label things as hate speech. Problem solved.

But some of us absolutely need that category.

[s3x-jay]

Let's say I'm morally opposed to people wearing bananas on their head. Should a designation for that be added to NIP-69? No? Why not? You don't think that that's a significant enough category? Why is "Coarse Language / Profanity" a valid category but "Banana Hats" isn't? That's you making a moral judgment on the PROTOCOL level. This is a line we don't want to cross. This NIP should be scraped entirely.

The "Coarse Language / Profanity" category is in there for two reasons…

• It's been an established content moderation category for well over a decade. It was part of ICRA back in the day. Most TV programs and films continue to use it as a basis of content ratings, etc.
• It's currently one of the 5 categories that are defined in NIP-56. I suspect (but I'm not sure) it was included in NIP-56 because it is a category required by Apple. Which means removing it may affect client apps' ability to be in the Apple App Store.

Also, please make note of the following part of NIP-69…

The fact that something is in a moderation vocabulary says nothing about the ethical or moral quality of that type of content.

There are no moral judgements being made here. Only observations about the most likely things that people will want to moderate. I, for one, could care less about coarse language and profanity. But others do care about it. The list isn't my list or Rabble's list. Yes, we're part of a community that needs to feel safe and content moderation is part of that. But NIP-69 isn't just for us - it's for many, many different types of people.

And it's worth noting that we can do monitoring after the fact on relays like nostr.build to see which categories are being used and deprecate the ones that aren't getting any use and elevate the most popular X-MOD categories to MOD. Nothing is set in stone here. It's just a NIP. It can be tweaked based on real-world usage. It's more about the framework at this point.

[staab]

Those of you who haven't seen it, please read the full conversation in the link.

Please do read the entire conversation, @s3x-jay's summary badly misrepresents my position.

[mikedilger]

Whether this NIP happens or not, I won't use it, and I don't support it. But it won't bother me either way. Users can choose to use it via a content plugin to be developed, or they can use their own terms defined in other dictionaries, or whatever. I'm all about empowering users to do it "their way" not "my way." This NIP is about "s3x-jay's way" or maybe "left-wing American society's way" which is strange to bake in at the protocol level. If someone in Germany were doing this NIP it would have different categories. If someone less obsessed with sex work were doing it, it would have different categories. The categories are highly context sensitive and therefore I feel nobody is qualified to make such a NIP.

Categorization is not objective, it is subjective, and many of us feel that modern society is deeply corrupted by compounded category errors (yes, you can quote me on that). As @staab puts it, "we all know the world has lost it's mind and its standards mean nothing." I agree wholeheartedly, even as I adhere to quite different politics (I am a classical liberal atheist who supports the right to abortion and believe sex work is fine work). Hell, even naming isn't objective (which is why nostr started early on with a 'petname' scheme, to distribute naming itself).

Statements like "It's been an established content moderation category for well over a decade. It was part of ICRA back in the day." are appeals to society.... a society that most of us feel has "gone utterly mad" and so they hold no weight among us.

Let's not get hot-headed about it as if free-speech itself is doing to die if this gets accepted. It will just be another ignored NIP among dozens of others. Nostr will work fine without it, and those who want to use it can go ahead and use it to their heart's content. We don't have to be among them. NIPs are for documenting what people are actually doing, not for recommending what people should do.

[staab]

I think Mike is right that NIPs should be descriptive rather than prescriptive. If that's the case, and people are using the IH category, who am I to censor them (or in other words, practice "intolerance of intolerance of intolerance"). My apologies for derailing the discussion based on an individual category, that's not the key problem with this NIP.

In the spirit of constructive criticism, I went back and read the NIP and most of the conversation above. In general, I think this NIP is way too long and complex (it's hard to read and come away with a coherent sense of the whole), but it has some good parts:

• Structured labeling is a good idea. This allows people to use their own namespace, or reference an existing nomenclature.
• Being able to apply topics to another person's post is an interesting idea.
• quality, confidence, and support are good ideas, although JSON in tags is sort of ugly.
• l tags are a great addition (I don't think we need the redundant label tag). This allows moderation to be self-applied, and for reports to use the same primitive.

I do think defining a vocabulary here is a bad idea. Content moderation will always be reactive, incomplete, imprecise, and at least partially done by hand. I don't see how any level of precision in an established vocabulary helps operators get any closer to a guarantee that they are working with the correct content. If these categories are indeed subjective and depend on who is doing the labeling, broader categories will work fine because the meaning of those categories will be informed by the values of the person doing the moderation. Web of trust ideas are a more constructive way to handle this in my opinion. And if certain moderators want to publish a granular vocabulary and use that, great! But it shouldn't be specified by the protocol.

So I'm a NACK on this whole thing, but wouldn't mind seeing the above ideas folded in to NIP 36 and 56, which provide self-reporting and other-reporting mechanisms already.

[michaelhall923]

@mikedilger thanks for putting what I've been trying to say much more elegantly lol

@staab Also check out this PR for NIP-56, which abstracts "reporting" as "labelling", which would allow for applying topics to other people's posts #459

[s3x-jay]

I think Mike is right that NIPs should be descriptive rather than prescriptive. If that's the case, and people are using the IH category, who am I to censor them (or in other words, practice "intolerance of intolerance of intolerance"). My apologies for derailing the discussion based on an individual category, that's not the key problem with this NIP.

THANK YOU SO MUCH for giving the NIPs another shot. I really do appreciate it…

In the spirit of constructive criticism, I went back and read the NIP and most of the conversation above. In general, I think this NIP is way too long and complex (it's hard to read and come away with a coherent sense of the whole), but it has some good parts:

Did you notice that it was actually 2 NIPs not one? Labeling (NIP-68) really is something separate from content moderation (NIP-69) and it could be approved without NIP-69 if it came to that. PR 459 got me thinking about how labeling was a great way to reframe things. But, having worked with various defined vocabularies for decades now I found PR 459's approach too limited. If we're going to do labeling - let's do it correctly.

And yes, it was long-winded. Part of the reason for that was all of the comments above which lead to clarifications, and mentions of use cases to ease fears. I'm fine with it getting simplified.

* Structured labeling is a good idea. This allows people to use their own namespace, or reference an existing nomenclature.

* Being able to apply topics to another person's post is an interesting idea.

* `quality`, `confidence`, and `support` are good ideas, although JSON in tags is sort of ugly.

It's not the first time there's been JSON in tags. The data applies to the particular label, so putting them in content wouldn't really work. Plus Fiatjaf recently said that people shouldn't be putting JSON in content - they should put human-readable text in content.

Can you suggest a better way to structure the data? I'm fond of quality, confidence, and support but don't care how the data is structured.

* `l` tags are a great addition (I don't think we need the redundant `label` tag). This allows moderation to be self-applied, and for reports to use the same primitive.

Labeling can be used for things like reviews and recommendations. So it could be long-winded free-form text. It also gives the labeler a chance to explain context, etc. when the labeling is for content moderation. So label isn't exactly redundant with l. One is a code. The other is closer to a kind 1 comment.

I do think defining a vocabulary here is a bad idea. Content moderation will always be reactive, incomplete, imprecise, and at least partially done by hand. I don't see how any level of precision in an established vocabulary helps operators get any closer to a guarantee that they are working with the correct content.

Content moderation is already an overwhelming task for centralized systems. Whether it's Twitter, Facebook or MindGeek, there's never enough time to do it properly and users complain bitterly when it gets done "wrong" from their point of view. That gets many fold worse in a decentralized system like Nostr. Suddenly that same piece of content needs to be reviewed by multiple relays plus all the various community "gatekeepers" who do the shit job of sifting through potential problems so the members of the community can have a pleasant experience on Nostr.

There simply has to be some automation. And you can't have automation without a "language" for the various players to use. And bots really can do a lot - just as they do for corporate social media.

Without some level of automation and a way for multiple people/groups to benefit from the actions of a single moderator, there's simply no chance Nostr can keep up with content moderation. Without a common vocabulary there will be 100+ vocabularies and then translating between what each of them means is going to become a gargantuan task. It's not something a client app could do on the fly.

Remember - being very precise let's you filter less content, not more. Otherwise what happens is what Vitor is doing now - "oh, there's a report about this - I don't know if it's serious, so I better hide it…"

If these categories are indeed subjective and depend on who is doing the labeling, broader categories will work fine because the meaning of those categories will be informed by the values of the person doing the moderation. Web of trust ideas are a more constructive way to handle this in my opinion. And if certain moderators want to publish a granular vocabulary and use that, great! But it shouldn't be specified by the protocol.

When I first started trying to figure this out I was shooting for zero subjectivity. You can see that somewhat in my nudity/sex/porn categories. Some of the classification systems I'd seen in the past had categories like "Not suitable for children under 18 years of age" - which is totally subjective. So the nudity/sex/porn stuff is as objective as I could get. The early drafts were extremely specific - but they had too much complexity.

The whole point of the section about how NIP-69 should be used is based on the idea of web of trust… There came a point when I realized that the one thing Nostr can do that none of the centralized systems are willing to do is that on Nostr anyone can be a moderator (if we set things up properly). You can then trust people who think like you do and make them your moderators. Suddenly the subjective nature of the report doesn't matter - because it's only being used by people who see things the same way.

There's actually a change to NIP-69 which I asked Rabble to put up, but they haven't gotten around to which 1) lets you have positive reporting, and 2) lets you set "anti-moderators" - so you can basically have the opposite moderation that someone suggests. It's a way of turning what someone may see as a negative ("unjustified censorship") into something positive - whatever they say to censor actually gets the content more exposure, not less.

So I'm a NACK on this whole thing, but wouldn't mind seeing the above ideas folded in to NIP 36 and 56, which provide self-reporting and other-reporting mechanisms already.

NIP-36 and 56 have a few issues. You can see in the commits that modifying those was the first thing we tried to do. They're just really limited. If you really want me to I can explain in more detail, but I feel like I'm already being long-winded.

But seriously - thanks for giving this reconsideration. I really do appreciate it!

[staab]

It's not the first time there's been JSON in tags. The data applies to the particular label, so putting them in content wouldn't really work. Plus Fiatjaf recently said that people shouldn't be putting JSON in content - they should put human-readable text in content.

Ideally data should be modeled using Pablo's approach of using tags to create key/value pairs. See here for an example.

Labeling can be used for things like reviews and recommendations.

In that case I would think label would be redundant with content. There has also been an alt tag discussed elsewhere, which could work if you want a summary.

Without a common vocabulary there will be 100+ vocabularies and then translating between what each of them means is going to become a gargantuan task.

This is true, but I'm not sure how to avoid that. Defining a recommended vocabulary doesn't mean it will be used. The idea of a standard nomenclature at all is the main sticking point of this whole PR. Since everything is subjective due to web of trust, you can't expect terms to mean the same thing anywhere, even if people use the same terms. I could see how a standard nomenclature would allow clients to fetch content based on the user's trust graph, but of course that doesn't assign a value to any given label either.

Maybe a good way to cut this knot is to explicitly assign responsibility for terminology to pubkeys. In other words, the only vocabulary in the system is that of a pubkey. What that pubkey endorses (with quality/confidence factors) can be considered an example of that pubkey's self-assigned term. A rudimentary example of this is the "porn search bot". You might have multiple pubkeys that claim to moderate the same term but execute differently, and a user/client/relay might choose to subscribe to one vs the other. This is obviously not easy/performant to query, but I think provides a much more robust model.

The whole point of the section about how NIP-69 should be used is based on the idea of web of trust… There came a point when I realized that the one thing Nostr can do that none of the centralized systems are willing to do is that on Nostr anyone can be a moderator (if we set things up properly). You can then trust people who think like you do and make them your moderators. Suddenly the subjective nature of the report doesn't matter - because it's only being used by people who see things the same way.

I agree with this, this is the holy grail of distributed moderation.

There's actually a change to NIP-69 which I asked Rabble to put up, but they haven't gotten around to which 1) lets you have positive reporting, and 2) lets you set "anti-moderators" - so you can basically have the opposite moderation that someone suggests. It's a way of turning what someone may see as a negative ("unjustified censorship") into something positive - whatever they say to censor actually gets the content more exposure, not less.

This is also a cool idea.

[olheadinternet]

this 100%

Maybe a good way to cut this knot is to explicitly assign responsibility for terminology to pubkeys. In other words, the only vocabulary in the system is that of a pubkey. What that pubkey endorses (with quality/confidence factors) can be considered an example of that pubkey's self-assigned term. A rudimentary example of this is the "porn search bot". You might have multiple pubkeys that claim to moderate the same term but execute differently, and a user/client/relay might choose to subscribe to one vs the other. This is obviously not easy/performant to query, but I think provides a much more robust model.

[michaelhall923]

Maybe a good way to cut this knot is to explicitly assign responsibility for terminology to pubkeys. In other words, the only vocabulary in the system is that of a pubkey. What that pubkey endorses (with quality/confidence factors) can be considered an example of that pubkey's self-assigned term. A rudimentary example of this is the "porn search bot". You might have multiple pubkeys that claim to moderate the same term but execute differently, and a user/client/relay might choose to subscribe to one vs the other. This is obviously not easy/performant to query, but I think provides a much more robust model.

Very interesting idea

[s3x-jay]

Ideally data should be modeled using Pablo's approach of using tags to create key/value pairs. See here for an example.

So the issue as I see it is that, as spec'd, there can be multiple labels and each one can have different parameters. Ergo it's difficult to break them out into additional tags. They're parameters of a particular l tag.

Take one of the examples and redo it the way you think it should be done and let's discuss…

In that case I would think label would be redundant with content. There has also been an alt tag discussed elsewhere, which could work if you want a summary.

I had to think back a second to remember why I made label label, not content… Yes, on type 32144 "reports" I agree - put it in content. But that's not the only time labeling is done. A person can also self-label at the time they publish an event. In that case content is used for other purposes.

This is true, but I'm not sure how to avoid that. Defining a recommended vocabulary doesn't mean it will be used. The idea of a standard nomenclature at all is the main sticking point of this whole PR. Since everything is subjective due to web of trust, you can't expect terms to mean the same thing anywhere, even if people use the same terms. I could see how a standard nomenclature would allow clients to fetch content based on the user's trust graph, but of course that doesn't assign a value to any given label either.

IMHO, if major apps use it, it will be used. You might not use "IH" (that's OK) and other apps may not use some others, but if enough apps use enough of the vocabulary then it will be used by relay owners in the least.

For example, my relay will ignore all reports of nudity, sex and porn (or we'll use those tags for content discovery - lol). We'll mostly focus on illegal content that present a legal liability for the relay as well as hate/intolerance as that's a pain point for the folks I'll be serving. CSAM and escorting will be things we'll have to act on quickly. But adult.18plus.social (another adult industry relay in the UK) won't have to concern itself with reports of escorting. Different laws, different concerns. But without the detail of which type of illegal activity is being reported we'll be hunting for a needle in a haystack, content won't get taken down and our relays will risk getting sued or shutdown.

Maybe a good way to cut this knot is to explicitly assign responsibility for terminology to pubkeys. In other words, the only vocabulary in the system is that of a pubkey. What that pubkey endorses (with quality/confidence factors) can be considered an example of that pubkey's self-assigned term. A rudimentary example of this is the "porn search bot". You might have multiple pubkeys that claim to moderate the same term but execute differently, and a user/client/relay might choose to subscribe to one vs the other. This is obviously not easy/performant to query, but I think provides a much more robust model.

Can you explain further what you mean? Is it covered by the "moderator lists" section of NIP-69? Or are you talking about something different?

But that did bring up a thought - it could be taken a step further and users could have a list of which of the categories in the defined vocabulary they care about and which they don't. Then the apps could just skip over all moderation reports that aren't of concern to them.

Point being - there are a lot of cool things that can be done to filter people's feeds - but many of them depend on there being a vocabulary that's used by a critical mass of people.

I agree with this, this is the holy grail of distributed moderation.

I love moments like this when people realize they're actually on the same page after a big argument!

This is also a cool idea.

I'll see if Rabble can get that change up today (I'm a newb on Git and don't have permission to change things). Or you can see it now at this URL…

[staab]

Ok, I just created a new PR that updates NIP-56 with some of the ideas mentioned here. I think it creates a solid primitive on which a lot of moderation, recommendations, and more can be built. #524

[mplorentz]

This PR is trying to solve two problems.

1. We need a way for users to label content on Nostr, for lots of reasons.
2. Completely freeform content reports (like what is seen on Mastodon) make them basically useless for moderation.

@staab has now modified #524 to the point where it is almost identical to NIP-68 (even copying and pasting some of the examples). I think there is enough common ground for @s3x-jay and @staab to combine them.

Then maybe NIP-69 could be put into its own PR. It probably could benefit from a little more storytelling around the problems with unstructured labeling and how clients, relays, and users might apply these labels without creating the same problems we have with Big Social's moderation. Not in the NIP, NIPs should be about the semantic meaning of data (which is exactly what NIP-69 is), but maybe in the PR. Happy to help out with that if it's useful.

[staab]

I think there is enough common ground for @s3x-jay and @staab to combine them.

They are very similar! Looks like I went on a journey to end up the same place. Some important structural differences, but yeah, it probably would be most productive to split this into two PRs.

[s3x-jay]

@staab has now modified #524 to the point where it is almost identical to NIP-68 (even copying and pasting some of the examples). I think there is enough common ground for @s3x-jay and @staab to combine them.

Then maybe NIP-69 could be put into its own PR. It probably could benefit from a little more storytelling around the problems with unstructured labeling and how clients, relays, and users might apply these labels without creating the same problems we have with Big Social's moderation. Not in the NIP, NIPs should be about the semantic meaning of data (which is exactly what NIP-69 is), but maybe in the PR. Happy to help out with that if it's useful.

68 & 32 are not the same. They should not be merged. For starters non-replaceable events are a non-starter for labeling. And last I looked 32 had cases were considerable free form text was being put into an indexable tag. There’s probably more but dealing with the details is not my priority right now. (I’m in the hospital).

Then there’s the issue of process… The fact that you were comfortable stealing portions of my work, putting your own name on it instead of simply implementing 68 or discussing changes you needed to it says volumes. That’s not how NIPs should be created.

So no, I do not want to see them merged.

[staab]

stealing portions of my work, putting your own name on it

1. NIPs are public domain
2. I added your name to the authors section of Add NIP-32 for labeling things in nostr #532 in appreciation of your contributions here
3. This PR hasn't been touched in a month. I'd rather not edit someone else's work uninvited, so I made my own PR.

If you read through the comments on #532 you'll see that replaceable events are still being discussed. I intend to add them when I have an opportunity. If you prefer and have time (get well soon), I invite you to split this PR into 68 and 69 and incorporate what I've learned in drafting #532 and we can merge that instead.

[mplorentz]

For transparency @staab and @s3x-jay and I have been talking about combining 32 and 68 in various mediums other than Github. Some of it is publicly viewable in this Zulip space.

[staab]

Superseded by #532