Please let me know what you think about this (but only if you agree):
nostr:naddr1qqyrxvf3vgunjwt9qyghwumn8ghj7enfv96x5ctx9e3k7mgzyqalp33lewf5vdq847t6te0wvnags0gs0mu72kz8938tn24wlfze6qcyqqq823czkn5qp
Discussion
nostr:nprofile1qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qyg8wumn8ghj7mn0wd68ytnddakj7qg3waehxw309ahx7um5wgh8w6twv5hsqgzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtsnyw5n2 nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcpz9mhxue69uhkummnw3ezumrpdejz7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qg3waehxw309ahx7um5wgh8w6twv5hsqgpjuxp8vd29p6ancknaztql3eajk52y8xkppfn7au7elkw9c68zg5w6awvc nostr:nprofile1qyghwumn8ghj7mn0wd68ytnvv9hxgtcpz9mhxue69uhkummnw3ezuamfdejj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hsz9nhwden5te0wfjkccte9ekkcettw5hxgetk9uqzphtxf40yq9jr82xdd8cqtts5szqyx5tcndvaukhsvfmduetr85ce4znfpm your considerations would be appreciated.
We've been building for over a year, with a whole set of new kinds, without a single NIP for any of them, and nobody has yet died.
I find the kind list and tag list on the readme most interesting, to make sure I don't accidentally reuse a popular number, and to peruse existing data structures. I sometimes dig stuff up out of PRs, like public messages, and implement it. I don't bother to wait for a NIP.
Either it's a good idea, or it isn't. The bad ideas eventually just peter out, and I decide for myself which ones are the good ones.
New devs often ask me for advice on NIPs to use and I direct them to open PRs that I'm following, but they're sometimes scared to use them.
NIPs are fine. Most people take them way too seriously though. It's just a place to interoperate. We need a place for that.
To me, NIPs are a reflection of usage. If that is what we want to do, we can create a portal where each client/relay declares their support for NIPs and the most supported one become an official nostr list. If clients drop support over time, they disappear from the list. A backwards way of developing specs, but one that trully represents what Nostr is about.
I agree, that's why I want to get rid of them.
The way they exist now gives too many wrong impressions. People see a central registry of NIPs and think that is "the Nostr protocol", when in fact many of those NIPs are not used already (or most people agree they shouldn't be used) and we can't touch anything on the list because it is a very serious list. At the same time there are many kinds being actively used with multiple implementations that aren't merged on the repo, and, most importantly, the way in which each kind is or should be used is not in the repo either.
Once the "official NIPs" aren't a thing anymore someone (or actually many people) can create independent registries that track implementations or do the job the current NIPs repo is doing, but much better and in a more fluid, opinionated way.
I don't know... I was hoping we could have a better portal for NIPs inside of Nostr. But all implementations for that kinda suck.
Yes. Probably because NIPs are the wrong abstraction. But also because we're stretched too thin trying to make all the things "on Nostr" at the same time.
If the kinds weren't numbers but instead m / M tags, you would barely even need a centralized table to go and see what number is what content type. Since the tag in the event would already give you the general category.
You mean if kinds were strings instead of numbers? Yeah, maybe, but essentially it would be the same thing (just from the name you can't get all the context regardless, like the schema, the ecosystem around it, the expected UXetc) and even if what you cite is a minor advantage there are also minor disadvantages (more bytes used, slower to parse, people still have to check some registry to see if they're typing the correct strings, names don't really correspond to anything so one would still have to check guides, names can actually give people the illusion that they understood or can be deceiving etc).
Yeah, good points. Although you have MIME to lean on. At least that's how nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z and nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku propose it in their spec.
In any case, I'm all for moving the specs away from a central repo and into wikis. That then can be grouped in an index that can be referenced in actual App Releases.
We have m and M tags, and we use them. But I see them as explanatory and especially useful for more specialized kinds, like 30040s, so that people can understand what they are seeing in the wild. They're also useful labels for events, in search results.
I don't see the value in only having them, tho. I like kinds. Precisely because they are more ambiguous and don't feign exactness.
I don't really get the point of NIPs because I just search the repo for a kind number.
Can we start by fixing this note? It does not have a `q` for quoting nor `root` for replies nor `mention` I think everyone should follow the standards properly its becoming troublesome to maintain 😂 nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgsm3u0w6