Some people think they can use NIP-32 labels "L" and "l" as key-value pairs to be queried on relays as if they were MongoDB instances.

That was never the purpose of NIP-32 and doing this is not going to work in the long term and will only lead to centralization and proprietary protocols, not standards, built on top of Nostr.

Specific, hardcoded kinds and tags, is infinitely better.

Reply to this note

Please Login to reply.

Discussion

On current trend, what year will there be more NIP’s than RFC’s?

I co-sign this, a good heuristic when using NIP 32 is that >1 note should be returned for any given `l` tag

What’s the best way to reference a unique ID from another protocol / namespace that doesn’t have a canonical url?

Obviously I am thinking about podcast feeds / episodes for which the guids (unique ids) are supposed to be honoured by hosting companies when you switch providers.

Another example might be book IBSNs.

Wouldn’t it be useful to have a way to tag these entities according to these agreed IDs that aren’t tied to any one platform? (as opposed to just putting in platform specific links that might not work in the future)

Wouldn’t it also be useful if these tags could apply to any event kind so that nostr users could find all the activity related to a given podcast episode / book - whether it’s a comment / long form text review / live stream with the creator of the original content?

What do you think the best approach for doing this is?

(my reading of NIP-32 was that this was what it was for but maybe I’m wrong)

Or would the standard “r” tag just work?

[“r”, “podcast:guid:123”]

[“r”, “book:isbn:123”]

Or NIP-48 proxy?