relax requirements for NIP 32 L tags

[staab]

l tags are really useful as a general-purpose indexable value. Adding L in many cases doesn't really help anything, and is quite ugly. Use cases:

• Language: ["l", "en-US"]
• Indexing 31337 creator: ["l", "Ainsley Costello"]

[vitorpamplona]

It's amusing how we've had to devise a complete labeling/namespace tag setup just to work around the fact that Nostr relays can't index the second value in tags, can't index tag presence, and can't do a simple startsWith query. All in the same NIP.

[alexgleason]

Shouldn't we at least include the namespace in the third position of the tag? eg ["l", "en-US", "ISO-3166-2"]

[staab]

Shouldn't we at least include the namespace in the third position of the tag? eg ["l", "en-US", "ISO-3166-2"]

I think it's probably best to just make the mark optional since in the 31337 case above the event's kind acts as a sort of namespace. This accommodates more informal usage which seems to be how people tend to use this (although I appreciate your use of the namespace field in gleasonator's feeds).

[alexgleason]

Language should not be en-US, ideally it should be just en marked with ISO-639-1

I want to be able to distinguish between ["l", "en-US", "ISO-3166-2"] and ["l", "en", "ISO-639-1"]

[staab]

That makes sense. Reviewing the music NIP, we've actually moved away from using l anyway. I've make the mark a SHOULD and specified that its absence indicates ugc.