users can label an account as being an organization, a "benign bot" (i.e. nostr-commits bot), a nsfw account, a celebrity, etc.

Should I add these/more examples to the NIP?

I would think we would want to just modify kind 1984 right? Since a report is simply a "type" of label. I don't see the need for two separate kinds? In fact, the reason I proposed this was to consolidate all of these kinds of things under 1 kind.

I would think we would want to just modify kind 1984 right? Since a report is simply a "type" of label. I don't see the need for two separate kinds? In fact, the reason I proposed this was to consolidate all of these kinds of things under 1 kind.

That could work. The current proposal is a strict superset of 1984 so I can just change the filename to 56.md and add a section or two and it should be good.
I went with a seperate kind initially as I believe some may want to treat moderation requests specially, but this could be done through another way than having two different kinds.
I'll put something together.

I would think we would want to just modify kind 1984 right? Since a report is simply a "type" of label. I don't see the need for two separate kinds? In fact, the reason I proposed this was to consolidate all of these kinds of things under 1 kind.

Okay, it's just one kind now. Take a look. Reporting hasn't been changed, it was simply made a part of a more generic kind.

may want to treat moderation requests specially

My thinking with this is "judgements" shouldn't be made at the protocol level. The data should be as objective as possible and up to the clients/relays to interpret it.

My thinking with this is "judgements" shouldn't be made at the protocol level. The data should be as objective as possible and up to the clients/relays to interpret it.

The difference between a label "spam" for a post discussing spam and "spam" in a report is very different. It should be expressed somehow. Though, the difference could be made in a way that doesn't involve the protocol. Something like report:spam as the label.
It could also be solved by giving context on what you're labeling. Something like content:spam vs discusses:spam vs image:spam, another field in the tags array?
How about we make the fourth +/- field into an array of context, "+" and "-" just being one option, "content"/"discusses"/"image" could be put as well.

Edit: A single string works better for filtering.

I think this is a step in the right direction, here's a few changes I would propose based on the conversation over at #457 (comment):

• This might be considered backwards-incompatible, but it would be nice to be able to specify more dimensions to a label, including quality, confidence, and context. I would envision this as additional tags that apply to all e or p tags mentioned. This would mean multiple labels could no longer be applied on a single event, but I actually see that as an improvement.
• Moving the label from a mark to an l tag would make these labels queryable.
• Structured/namespaced labeling as described in the draft for NIP 68 would allow a more granular labeling approach for people that want it, either to refer to an existing standard, or to create a proprietary namespace of some kind. Nothing in this NIP prevents that.

Other suggestions:

• Instead of including a p tag, why not directly include one or more r tags, if the purpose is to facilitate routing? It would be useful to be able to label pubkeys as well using the same mechanism (as the old version had it).
• I don't see much value in classification, but affirmative marker is a good idea. Maybe that could be expanded via quality as described in the NIP 68 draft to a range of -1 to 1 (i.e., -1 quality says this is not an example of the label).

So NACK on the current draft, but I think the general direction is a good one. As many of the above features as can be included in a backwards-compatible way (probably not l tags unfortunately) would get my vote.

I don't see much value in classification

How should "spam post vs discussing spam vs image of spam" be solved?

Instead of including a p tag, why not directly include one or more r tags

Addressing via public-key is better as URLs can change or go down and notes can move.

l tags

Just extend t tags, the only specification they currently have is a single sentence at the bottom of NIP-12.

I like the idea of using tags instead of fields appended to e/p tags for better filtering, I'll change this NIP to do that. It will have to be moved away from the 1984 kind but that's a bit of a non-feature now that I think about it again.

How should "spam post vs discussing spam vs image of spam" be solved?

I would expect "spam post" to be a label, while a discussion or image of spam would be a topic. The structured labeling suggestion from the 68 proposal allows attributing topics to other events.

Addressing via public-key is better as URLs can change or go down and notes can move.

Yes, but you first need to find the person. Also, relay hints in nostr are always relay urls to my knowledge, not pubkeys.

Just extend t tags, the only specification they currently have is a single sentence at the bottom of NIP-12.

Hmmm maybe. I'm all for conflating similar use cases normally, but topics are so much a part of UX I think a separate tag type for stuff that shouldn't always be surfaced to the end user would be a good idea.

It will have to be moved away from the 1984 kind

I'd rather not introduce another redundant kind, that still results in more complexity for implementers. l could be an ok addition to the kind though, I'm not sure.

There's not really much of a deprecation path for Nostr from what I can tell, seems like there's going to be redundant kinds.

Nope, backwards compatibility is basically required, new ways to do the same thing is very bad. If we can find a way to shoehorn the new functionality into the old format, we should do it.

+1 to namespacing. That could even solve the classification problem as different standards can come up with their own ways of differentiating i.e. "spam" vs. "about spam"

Is there a simple way to do an unnamespaced search with that system? That's something that will come up a lot. If there was some other way to introduce AND queries that would be great.

I'd rather not introduce another redundant kind, that still results in more complexity for implementers. l could be an ok addition to the kind though, I'm not sure.

Yes the purpose of this NIP was to decrease complexity not increase it lol

We'll just include a formal syntax for namespaces and remove the classification field. We could even prefix labels with a - instead of having the affirmative marker field. In fact, if we remove all the extra fields we could end up in a place where multiple labels could be included in a single array.

Edit: We should keep the affirmative marker field.

I really do like the system used in the other NIP that uses the same tags as those you use to label your own notes.

My problem with namespaces is that it's impossible to ignore. Allowing any namespace is great for evolution, but as we know people will never agree so it's going to be impossible to find anything when we're all using different namespaces.
My reason for having the classification as a seperate field was to introduce an escape hatch so that you can query everything if you want to. It also allows filtering for multiple namespaces at the same time which can help to alleviate the problem.

That's a compelling reason, I'd be fine with adding the namespace as an extra field

quality

I don't want to change the affirmative marker to a floating point number as then it couldn't be filtered and @michaelhall923 earlier said that he would want to completely ignore negative labels.
I was thinking about adding a ~ option which would be equivilent to a 0 in the -1 to 1 range but decided it wasn't needed.

confidence

It's no different from quality.

context

I see classification as accomplishing the same as a namespace or a context field would, am I missing something?
I could rename classification to context, that's what I originally called it after all.

but topics are so much a part of UX I think a separate tag type for stuff that shouldn't always be surfaced to the end user would be a good idea.

t tags are fine, but they're severely limited - they can only be set by the person making the post and have no context. Part of the reason I want labels in my client is for other users to be able to vote down inaccurate hashtags.

It's no different from quality.

Quality is objective, confidence is subjective. Quality is about how closely something fits a definition (I'm 80% libertarian), confidence is how sure you are about your assessment (you're 50% sure I'm 80% libertarian). This is an approach New Founding took (unfortunately their guide is no longer online).

I see classification as accomplishing the same as a namespace or a context field would, am I missing something?

I think that's right, namespace and classification seem the same. Context would just be additional events meant to help a human moderator make a decision.

t tags are fine, but they're severely limited - they can only be set by the person making the post and have no context. Part of the reason I want labels in my client is for other users to be able to vote down inaccurate hashtags.

If you look at the PR for NIP 68, they do this using qualified labels, e.g. #t>butter would be a way to assign the "butter" tag to some other event. In this version, I would think something along the lines of ["e", <eventid>, "butter", "t"] would be equivalent.

Quality is objective, confidence is subjective.

Seems like an interesting way of going about it, dunno how I would make it work with the affirmative marker field. A catch-all stringified JSON field like the other NIP seems convenient, but messy. I could still go for it.
Have we added comparison filters like quality > 0.8 yet?

Context would just be additional events meant to help a human moderator make a decision.

I see, I see. I think the content would do something similar in this version.

In this version, I would think something along the lines of ["e", , "butter", "t"] would be equivalent.

Yep, that would be acceptable. Could also use "topic" for the last field.

Ok, I just created a new PR similar to this one, but which pays a little more attention to backwards compatibility, and adds some of the stuff in from 68/69. #524

Superseded by NIP-32.