nips
nips copied to clipboard
relax requirements for NIP 32 L tags
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"]
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.
Shouldn't we at least include the namespace in the third position of the tag? eg ["l", "en-US", "ISO-3166-2"]
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).
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"]
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.