As I delved deeper into the Nostr network protocol, I found myself struggling to navigate the Nostr Implementation Possibilities (NIPs). Each NIP contains a wealth of information, but it's often obfuscated by noise, making it challenging to understand what each one is trying to convey.

For instance, when I tried to figure out what the `"e"` field would do, I went to read through the first document. But instead of finding a straightforward programming guide, I was confronted with blocks of text that read like a nuclear safety manual. It was a frustrating experience, to say the least, highlighted by the fact that the information I needed was buried in the last paragraph, long after its actual use within the same document.

To make matters worse, I'm never sure if the NIP I'm looking at is the right one for my problem. And with so many NIPs available, it's difficult to determine which one is relevant. Moreover, searching for information in NIPs is a pain. I often wonder if all the relevant information is contained within a particular NIP or if I should be looking at other NIPs as well.

Furthermore, I find it perplexing that app layer things are being mixed into the "protocol." Why is there a NIP for browser extensions, for example? This NIP, by itself, blocks developers from creating alternative solutions since it's considered canonical. It's worth noting that there is no Ethereum Improvement Proposal (EIP) for `window.ethereum`, yet everything still works perfectly fine.

The sheer number of NIPs is already mind-boggling. As of April 2023, there are at least 30 NIPs in the repository, with nondescript filenames like `01.md` only adding to the confusion. There are also 82 open pull requests (PRs), suggesting that people view NIPs more as a validation for their app ideas rather than a base protocol for notes.

In conclusion, I believe that if NIPs are necessary for app layer development on the Nostr network protocol, they need to be improved significantly. They need to be clearer, more organized, and easier to navigate. Otherwise, users like me will continue to struggle with them, making it challenging to contribute to the Nostr network protocol's development. One potential solution could be to make them more like traditional programming documentation or create a ChatGPT-like search for NIP content. Since NIPs are describing JSON objects, we could document them as such, making them more accessible to developers and users alike.

Reply to this note

Please Login to reply.

Discussion

As far as standards go, nostr is famous for its accessibility. And many in the community - including me - think we need more nips, not less.

Why do we need [07.md](https://github.com/nostr-protocol/nips/blob/master/07.md)? Well, it helps those working on browser clients and browser extensions to coordinate their efforts. If you are not working with the browser, you can ignore that nip just like I would ignore other nips that - thanks to my contributions to their discussions I'm even featured as co-author of.

I agree that some see nips as "validation for their app ideas" and that's problematic. It's also why the [Readme](https://github.com/nostr-protocol/nips) states as first "Criteria for acceptance of NIPs": "They should be implemented in at least two clients and one relay -- when applicable." and sometimes we ignored Rule 1.

But formalizing ways of doing things help with interoperability. So I'm all for a nip on how chess clients work. I see the problem in the centralized repository where such a nip would be a distraction. The Jester guy would care about such a nip. Not me. But just as I care about the interoperability of social clients, I very much hope for interoperability for long-form clients like Habla or for ride hailing apps.

If not on GitHub under Fiatjaf's reign, where to best [consolidate implementation proposals](https://habla.nostr.info/a/naddr1qqdxsmmh23h5xmmwwdhkc6tyv96x2nr0den5vmmjd4zkuqg4waehxw309aex2mrp0yhxgctdw4eju6t09uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshszenhwden5te0ve5kcar9wghxummnw3ezuamfdejj7mnsw43rzemdxa682anj89shgcekw5mhzvm8v4mx5en909n8jandwfk82mp50ymrw6ehw5mkscmc0f685d3hvdjk27rnxqmnsunxxclkyun0v9jxxctnws7hgun4v5q3zamnwvaz7tmwdaehgu3wwa5kuef0qyg8wumn8ghj7mn09eehgu3wvdez7qgwwaehxw309ahx7uewd3hkctczypr0e03svh40rtncz9r9jf8y3y3nv0ln75nt6mmn6lqcfvttmr8y6qcyqqq823cgtg38y) though?