Ok nostr:nprofile1qydhwumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6tcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy88wumn8ghj7mn0wvhxcmmv9uqzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vanaunjh you win, NIP 32 was a mistake. I still think it has valid use cases, but it looks too much like an infinitely flexible sub-protocol and is constantly being misunderstood and misused.
Discussion
My misunderstanding isn't an indictment of NIP-32 lol
Pretty much everyone (including myself) struggles to understand the proper scope of NIP 32. It's too powerful
I’ll bite. How is adding labels to notes broken?
Labels seem like they could be used as a generic entity/attribute/value database, which creates an entirely schemaless sub-protocol within nostr. This makes people feel like they can do whatever they want and it'll magically work with no specification of the details.
The intention was for people to define namespaces and vocabularies for classification, since ontologies are an impossibly open-ended problem. But pretty much no one does that, instead just creating ad-hoc key/value pairs. But labels should have cardinality > 1, which is not what values are. This is bad for relays too, which have to index all the `l`s.
It could work fine, but something about the nature of the protocol, or maybe what people are used to, makes it more confusing than helpful.
Tell the truth, you said that only because I used it inside a kind:0 in my nproduct proposal, and you want to move to a new kind!
😈😂
To be honest they felt like a good idea to me when I first read the NIP.
I still like them as tags assigned by a third party. We could rewrite the NIP to be just that.
Basically removing the self-labeling part? That would make it clearer.
Infinitely flexible sub protocols don't sound as bad when you call them that. Actually it just sounds like a fancy way of saying NIP. 🤣