@Gruruya multiple labels is now supported, see the examples section.

https://github.com/staab/nips/blob/nip-32-labeling/32.md

l should be able to have more elements so you can do multi-element tags. Also split the second element into two, you can keep a strange convention like ["#t/", "chickens"] if you want to keep the queryability.

It may be more efficient to default to applying tags to the referenced thing rather than putting it behind an l tag so it could be a single query to match both the event's tags and tags added by these label events. Clients are usually filtering by kind anyway, so it wouldn't effect them.

so ["t", "chickens"] would apply to the referenced event rather than needing to do ["l", "#t/chickens"]. We would then need to make a context tag where you could put all of the references, etc. tags that apply to the labeling event itself. Or just default to interpreting reference tags specially.

I also want to add a third namespace field to t tags which would default to namespace: topic which would let us use t tags for more than just hashtags, for instance tagging images, and would let you differentiate "spam post" vs "discussing spam" vs "image of spam" without resorting to boutique formatting like ["t", "image:spam"]

The other boutique formatting I expect to see is ["t", "-spam"] to mean "this is not spam," the quality in this NIP can act as a good band-aid to the lack of negative tagging in Nostr, which is not just a problem for labels. I think a generic negative form of tag should be described, something like ["-t", "spam"] or ["negative", "t", "spam"]. That said, most things don't need to be "explicitly not specified" and having it as a field/tag just in labeling is probably fine.

The tag agnostic nature of the NIP means it can adjust for whatever, so that's good.

Yeah, I think everything above is covered by this NIP, since labels can be anything you want. So for negative matches, ["l", "-spam"] with a quality of 1 would be equivalent to ["l", "spam"] with a quality of 0, just queryable differently.

I think one thing we're not quite in agreement on is the difference between labels and tags. In my mind, tags are not a generic labeling mechanism, but a core part of the experience for the end user. Polluting t with machine-generated or non-topical content is a bad idea.

So,

I also want to add a third namespace field to t tags which would default to namespace: topic which would let us use t tags for more than just hashtags, for instance tagging images, and would let you differentiate "spam post" vs "discussing spam" vs "image of spam" without resorting to boutique formatting like ["t", "image:spam"]

Should be handled with a flatter hierarchy by just putting the second-level namespace in the label, e.g. #t-image/spam. But again, I don't think it makes sense to use #t here because #t/image/spam would create a image/spam topic, which would not be idiomatic for hashtags from an end-user perspective.

l should be able to have more elements so you can do multi-element tags. Also split the second element into two, you can keep a strange convention like ["#t/", "chickens"] if you want to keep the queryability.

I don't see what this accomplishes, it seems like it adds more complexity while also removing the ability to query specific labels. Maybe an example?

I don't see what this accomplishes, it seems like it adds more complexity while also removing the ability to query specific labels. Maybe an example?

No, you're right. Doesn't accomplish anything, and keeping t tags simple makes sense.
I wanted to add these things to t so that it could be set in the original event, but it's alright. We should just use these labeling events for everything. It should be specified how to include more elements in an l label though i.e. prefixing every element.

The "lightning/channel" example made me think that maybe you should add required (relays may validate it) ["L", <vocabulary>] tag to help requesting just what the client supports

{
  "kind": 1985,
  "tags": [
    ["e", <id>],
    ["L", "nostr"],
    ["L", "ugc"],
    ["L", "none"],
    ["l", "#t/permies", "nostr"],
    ["l", "nintendo quality", "ugc"],
    /* edit: */ ["l", "brincante", "none"], // pt-BR slang that couldn't be auto-translated to english
    ["l", "triple A", "none"]
  ],
  "content": "",
  ...
}

Available vocabularies:

• nostr: like you defined, use #x/value convention
• nostr.nipXX: use nipXX defined vaules
• ugc: user generated content (client takes no responsibility, may just try to auto-translate it to english). edit: lowercase words in english with allowed space between them
• none: without spec; e.g.: client presets that can change anytime

Custom examples

• io.damus: vocabulary that damus has created

I don't see why we couldn't add l tags to regular events, that would make sense, although it probably wouldn't get a lot of support.

It should be specified how to include more elements in an l label though i.e. prefixing every element.

Do you just mean more examples for e.g. labeling something with a relay or whatever?

I don't see why we couldn't add l tags to regular events, that would make sense, although it probably wouldn't get a lot of support.

No need. The features I'm talking about are quality and confidence as seperate elements. I don't think it's a bad idea to do it this way. Also, I would interpret an l tag in a regular event as labeling whatever it's referencing.

@arthurfranca very interesting idea. I guess the tradeoff here is being able to query all namespaces simultaneously rather than one at a time, but the two formats contain equivalent information. I like my version better, since if you want to query multiple namespaces you can just add more entries to your l list.

["l", "#e/id", "#e/url", "#e/marker"]

I'm not sure what this means, can you elaborate?

I like my version better, since if you want to query multiple namespaces you can just add more entries to your l list.

You mean one could request this filter: { #l: ["io.damus.food", "io.damus.food.chinese"] } or even { #l: ["io.damus.food", "io.damus.food.chinese", <...all damus filters>] }?

But what if the client supports user generate labels that could be anything (almost), I'm talking about a steam-like system. In such a system, there is no fixed set of values. Steam allows any lowercase tag in english that can have space between words. "ugc" maybe should be exactly that: "any lowercase tag in english that can have space between words"

A client would have to request all label events for a specifc object and then filter out labels that don't follow the "lowercase english that can have space between words" client-side. Instead it could do { ..., #L: ['ugc'] }

I’m in the hospital and can only type with one hand, so unable to give a full set of comments. But one thought…

Have you gotten any feedback from experts or people with considerable experience in either content moderation or labeling (e.g. scientific or industry use of structured vocabularies and the like)?

I would think their input needs to come first. Otherwise you’re just working on something that will need to be deprecated in the near future as experts come in and find things that need to be changed.

["L", "nostr"],

Meta-labeling, I like this idea. Should keep it simple though, only put the current system and the structureless version in the NIP.

["l", "#t/permies", "nostr"],

The l array can have more than one element so this can't work, it's the same with quality/confidence, you need to seperate events based on these things.

Otherwise you’re just working on something that will need to be deprecated in the near future as experts come in and find things that need to be changed.

It can't get more generic than this. There's nothing to deprecate.

But what if the client supports user generate labels that could be anything

This is why the NIP recommends using qualified tags where ever possible; unqualified tags are for informal use either by clients or by users.

A client would have to request all label events for a specifc object and then filter out labels that don't follow the "lowercase english that can have space between words" client-side. Instead it could do { ..., #L: ['ugc'] }

I see, that makes more sense, I'll look at adding it to the spec.

@s3x-jay I haven't, but the purpose of this NIP is to leave the structure completely open. I have studied semantic web a little bit, but for the most part it seems like a never ending hole of pedantry. If someone wants to implement semantic web ontologies, they should be able to do so using this NIP, since labels can be anything. Do you have a recommendation for a quick primer on the problems you're referring to? I've read some Nikitia Bier, but not much else.

["l", "#t/permies", "nostr"],
The l array can have more than one element so this can't work, it's the same with quality/confidence, you need to seperate events based on these things.

@Gruruya remember that nostr relays only indexes the first "value" of the tag ("#t/permies"), so multiple labels like ["l", "romance", "sci-fi", "horror"] wouldn't be searchable (just "romance" would). You would have to use 3 separate "l" tag arrays.

@s3x-jay I haven't, but the purpose of this NIP is to leave the structure completely open. I have studied semantic web a little bit, but for the most part it seems like a never ending hole of pedantry. If someone wants to implement semantic web ontologies, they should be able to do so using this NIP, since labels can be anything. Do you have a recommendation for a quick primer on the problems you're referring to? I've read some Nikitia Bier, but not much else.

Experts need to be involved. I’m not an expert on these things, but I have been using labeling systems / defined vocabularies for over 2 decades - including modeling my own vocabulary (based on the lessons I learned working closely with MesH for a few years) that powers/enhances the tagging system on my sites.

Is there a reason why you don’t just use NIP-68? Other than the reserved vocab values 68 really has nothing to do with 69. And it avoids some of the problems I see you making.

The reasons I'm creating a separate NIP from 68/69 are 1. it prescribes a nomenclature, 2. it's more complex than it needs to be. I've borrowed some of the ideas (e.g. qualified namespaces) for this NIP. I think something simpler and more generic is going to have more success with the nostr dev community.

Apart from the issue of nomenclatures, which I am avoiding here, what problems do you see with this NIP? What use case do you want supported that this NIP doesn't cover?

remember that nostr relays only indexes the first "value" of the tag

Oh man, I feel dumb. Thanks for fixing everything despite my complete misconception staab.

The reasons I'm creating a separate NIP from 68/69 are 1. it prescribes a nomenclature, 2. it's more complex than it needs to be. I've borrowed some of the ideas (e.g. qualified namespaces) for this NIP. I think something simpler and more generic is going to have more success with the nostr dev community.

Apart from the issue of nomenclatures, which I am avoiding here, what problems do you see with this NIP? What use case do you want supported that this NIP doesn't cover?

I’m in the hospital typing with one hand on a phone. I don’t have the time or energy to each you what I’ve learned over the past 2-3 decades. You’ve made your voice quite clear. No one will confuse your use of 68 as support for 69.

I’ve asked a data scientist with a background in biology to chime in about 68. Hopefully he’ll have time this week. I’m pretty confident it’s good, but want to be sure.

In my opinion, the bad thing with NIPs 68 and 69 is forcing all nostr to use the strict vocab>code scheme (cause all others go into an unsearchable "label" tag).

One, debatable, superior approach it presents, comparing to NIP-32, is having quality/confidence data per label along with extra useful things like "appliesto".

A different thing from NIP-32 (don't know if better or worse cause it is 2 ways of doing same thing) is allowing atomic labeling by the author of the original event (e.g.: author adding l tag inside its own kind 0 event, instead of creating an extra event).

It is very good for relays that NIP-68 proposes using parameterized replaceable events (there would be much less stale events). The trade-off is that the "d" tag format doesn't allow using just one event for tagging multiple events/profiles at once (or the graphs, like NIP-32 does).

What about you take the following from NIP-68/69...

{
  kind: 32144,
  // ...,
  tags: [
    ["d", <eventid of event being labeled (or pubkey being labeld)>],
    ["l", "MOD>NS-ero", "{ \"appliesto\": \"picture\", \"confidence\": 0.3 }"],
    ["l", "X-MOD>AB-cde"],
    ["l", "MOD>delete"],
    ["label", "crazy fantasy"]
  ]
}

...and turn into:

{
  kind: 32144, // parameterized replaceable event],
  // ...,
  tags: [
    ["d", <eventid of event being labeled (or pubkey being labeld)>], // not sure if this can be enhanced
    ["L", "nip69"],
    ["L", "ugc"],
    ["l", "MOD>NS-ero", "nip69", "{ \"appliesto\": \"picture\", \"confidence\": 0.3 }"],
    ["l", "MOD>AB-cde", "nip69"], // notice the "X" from X-MOD was removed. more on this below
    ["l", "MOD>delete", "nip69"],
    ["l", "crazy fantasy", "ugc"] // notice how it replaces "label" with "l"
  ]
}

Why drop the X from "X-MOD": "Non-standard (http) header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard.[6]"

using parameterized replaceable events (there would be much less stale events).

They're good for the reason you state, but they make it so you can only reference one thing (unless we can come up with a convoluted d tag creating procedure) and you can't append labels. IMO both are useful and a single-reference replaceable version of the event could be added.

allowing atomic labeling by the author of the original event

If we want to make l tag handling the same regardless of what kind the event it's located in is (concern raised by mikedilger,) the l tag must mean to apply the label to whatever the event is referencing.

Just pushed a new version, summary of changes:

• L tags are now supported (and required), defined as the namespace used in an l tag. This makes it trivial to add basic support for any nomenclature.
• Namespace within l tags is now in a mark to avoid parsing ambiguities (e.g. multiple slashes in a tag)
• Unqualified labels are no longer supported. Use a dang namespace, even if it's bogus.
• ugc is specified as a special namespace to support user generated content.

I'm pretty happy with the NIP at this point. The replaceable functionality is the last thing I see that's not resolved. If we had to choose between the two, I'd prefer the ability to add multiple tags to a single event at the expense of replaceability. But What might be preferable would be to add support for an optional d tag. Is there an event kind that "may or may not" be replaceable?

Is there an event kind that "may or may not" be replaceable?

I think there isn't cause there exists only NIP-16 and NIP-33. And parameterized replaceable event with no d tag in considered having an empty string d tag as identifier.

Although the NIP could define that it requires special treatment from relay (as for instance kind 0 metadata, that isn't in the range of replaceable events (10000 <= n < 20000), is implied to be treated as replaceable - this happened cause kind 0 was created before replaceable events NIP existed). But this hurts relays as they have to add extra logic specific to a kind.

L tags are now supported (and required), defined as the namespace used in an l tag.

Nice, this is good.

Is there an event kind that "may or may not" be replaceable?

You have to use two different kinds, I believe.

allowing atomic labeling by the author of the original event

I've though about this a bit more and a #self namespace or similar could work to accomplish this. May be worth adding. But just having labels in other kinds self-label by default works fine too.

it requires special treatment from relay

I definitely think this would be a bad idea. Another option would be to generate a UUID for the d tag. How bad would that be compared to a different kind? I personally don't like multiple kinds just to get the replaceability functionality, but I guess it's not that bad.

I've though about this a bit more and a #self namespace or similar could work to accomplish this.

The #e namespace refers to a different event than the one being tagged. So based on the namespace semantics, #self would be a self-reference, not in the sense of applying a label to self, but in the sense of labeling self with self, which is pretty silly.

Another option would be to generate a UUID for the d tag

Worse hack than having two kinds.
If we wanted to use one kind, we would have to figure out how to concatinate multiple references into a d tag. I say a non-replaceable kind is useful for appending so it may be worth keeping just for that. Though I guess a client could make a d tag by appending the labels to the reference or something other nonsense if they wanted to keep that functionality.

Worse hack than having two kinds.

Yeah, you're right. Another reason to create a new kind is that the replaceable kind would have different requirements, i.e. only one target tag. Does anyone desperately want the replaceable version, or should we keep the NIP simple for now? I see no problem with duplicate labels, if clients care they can de-duplicate based on pubkey plus their query.

NIPs are not meant to be exhaustive, nor prescriptive. Why don't you just go build your implementation and we can update the NIP to suit.

To be honest I've been wanting to shorten the NIP when I've been re-reading it. We could simplify it down to the main point of generic labels for indexing. WDYT?

NIPs are not meant to be exhaustive, nor prescriptive. Why don't you just go build your implementation and we can update the NIP to suit.

Because I should be able to use what others build and vice versa. That's kinda the whole point IMHO.

Breaks only having to query on l - which is why you'd use a delimiter.

What the hell? Why would you do that? Just use L
Anyways the l field has its namespace as its third parameter so you're point is moot.

Breaks only having to query on l - which is why you'd use a delimiter.

What the hell? Why would you do that? Just use L Anyways the l field has its namespace as its third parameter so you're point is moot.

Because using L returns “dirty” results, as I’ve explained many times now.

L exists because relays don’t support starts with searches (and many never will). L is needed when you want to find all the labels using a specific namespace (e.g. for a particular event). It’s not the best way to find all uses of a particular namespace>code combination. For that searching on just l is far more efficient.

For that searching on just l is far more efficient.

And it call comes down to this. It's simply more efficient for your use-case to use namespace>label and for mine to use label. Wouldn't it be great if we had a protocol that could accomodate both of us and have them both work?

At this point we're arguing over examples and it's probably better to just merge the thing and let us focus on implementing rather than arguing with each other. Any changes to examples can be made in a separate PR anyways.

NIPs are not meant to be exhaustive, nor prescriptive. Why don't you just go build your implementation and we can update the NIP to suit.

Some additional thoughts…

NIPs are absolutely meant to be both prescriptive and exhaustive - or at least enough so that people all do things in the same way. NIPs are not needed where someone just wants to do their own thing.

There is a rich history of labeling systems that existed before Nostr - systems that have a long history of collaborative use where people used the same coding system in the same way so they could benefit from each other’s use. The point of this NIP is to be prescriptive and exhaustive enough that that collaboration can continue on Nostr.

So my question is: in what scenario can you generically construct a namespace-merged l query like you're talking about without knowing anything about the vocabulary? In other words, the prefixed l tag fixes ambiguity, but you don't know a priori if a given namespace is prefixed or not. So you have to have a list of valid labels within a namespace, either explicitly (the client is coupled to the namespace, or there's a namespace definition document somewhere) or implicitly (by keeping track of labels that have been seen for a given namespace).

I really feel like we're over-thinking this. If clarity is required, bulk tagging across multiple namespaces should just be done using multiple events. Can we just go with that? I admire your thoroughness, but it feels like you're inventing new edge cases in an effort to create the perfect spec, which isn't going to happen in any event, rather than being practical.

NIPs are absolutely meant to be both prescriptive and exhaustive

This is the W3C way, not the nostr way. Nostr is permissionless, do it how you want, and reconcile differences later. The implementation is the standard, not the spec. Just wait until people start crafting deliberately malformed events.

It's simply more efficient for your use-case to use namespace>label.

I’ve been working with a variety of coding systems/vocabularies for 20-30 years. Every one I’ve encountered benefits from what I’m talking about.

I have asked repeatedly for a good example one one that doesn’t and haven’t gotten any specific examples.

Yeah you did?

So my question is: in what scenario can you generically construct a namespace-merged l query like you're talking about without knowing anything about the vocabulary?

I agree which is why I was initially pushing for everything to be prefixed then (when there was pushback) figured a note saying that well-defined coding systems (especially industry standards) assume prefixing.

bulk tagging across multiple namespaces should just be done using multiple events. Can we just go with that?

The database admin in me balks at the additional db records, but given how tags are indexed, I’m not sure if it’s as big of a problem as I might think it is.

The problem is labeling at the time of publishing. It would mean only one namespace can be used.

Otherwise, sure.

Just wait until people start crafting deliberately malformed events.

Trust me - that’s a big concern of mine.

Trust me - that’s a big concern of mine.

Me too, should be fun 😉

I read the proposal a few times but I'm not sure if I fully understand it, especially around label queries and how namespaces play into it. It might be useful to see examples of how NIP-12 queries would work with this.

You can see my implementation of relay reviews here, which is a nice concrete example. Namespaces exist to disambiguate between similar labels being used for different purposes, and to point to an authority or convention that is the basis for the label semantics. l and L are separate so you can query by label only (to query multiple namespaces at once at the risk of ambiguity), namespace only (to get all labels for a given vocabular), or both at once (for maximum precision). There are some edge cases @s3x-jay has pointed out having to do with clients tagging with multiple clashing namespaces at once, but they can be solved with some client-side filtering and/or not mixing namespaces with creating an event.

@fiatjaf would you mind merging this? @tyiu is planning to use it for calendar events as well.

I came here to ask if this was in a mergeable state. Are the nos.social people onboard with it too in its current form?

I came here to ask if this was in a mergeable state. Are the nos.social people onboard with it too in its current form?

I’m not technically part of the NOS team, but build 51 of NOS (available since yesterday) uses 32 + 69 for content reporting. I haven’t had a chance to study how NOS’ implementation works exactly but 32’s current form seems “good enough” to me personally.

I’m currently reworking 69 to reflect the changes from 68 -> 32.

Just pushed a small update to remove some redundant/exotic examples. I think this is good to go.

All right I'm just still going to use the "l" tag on my channel creation. This NIP allows for self-labelling, which is cool.

Cool, great work! We'll implement this in Arcade.

Yes this supersedes my placeholder NIP-32 from #46, closed that.