The end of NIPs

Many a time it has been brought up the fact that the NIPs repository is a central part of the otherwise fully decentralized Nostr protocol and some ideas have been proposed about how we should proceed to decentralize that part of it.

Two of the most reasonable approaches were (very simply) (1) for anyone to write their own version of the NIPs anywhere they wanted; and (2) to have a link from the NIPs repository to some "proprietary" specs defined elsewhere. Approach 1 has been more-or-less codified in the NUDs proposal (which wasn't really adopted) and approach 2 on the practice used a few times of "reserving kinds" in the NIPs repository README table.

Two frequent (and correct and good) arguments against "decentralizing" the repo were that (a) the current NIPs repo serves as a good discussion forum for new ideas and index of potential NIPs; and (b) some centralization is needed and good so developers are forced to cooperate and work on interoperability.

So here goes one idea that actually tries to satisfy 1, 2, a and b together while at the same time decentralizing the process as much as possible:

• We stop using the NIPs repository completely.
• We create a new repository, much less opinionated and contentious, only for reserving kind numbers and giving a short description to them.
• Anyone interested in any kind -- or group of kinds that work together -- writes a guide explaining how these kinds work and how they should be properly used.

With this simple approach we solve many problems:

• Most current NIPs are actually just schema descriptions of what tag is what and what is the shape of the events. It's kind of a waste of numbers and human memory to have to create a new NIP, get a number assigned and go through all the process (that has gone increasingly bureaucractic) just to define a new event kind with some small number of tags.
• NIPs that aren't like that, such as NIP-05, for example, would probably be better served by multiple attempts by different people at explaining the idea, each in its own way, such that the future implementor would have more options.
• Currently the text of the NIPs is often too short, it doesn't really inform developers about how exactly each event kind should be used in practice, the exact logic flow clients use, specially the part about choosing what relays to use at each step (which caused many developers to just focus on translating between event schemas as described in the NIP text and UI elements and disregarded the hard subtleties of relay choice, writing "clients" that only connected to a hardcoded set of relays). Because there may be difference in approaches the NIP text ends up not being a good place to write these things, but different personal articles written by people personally involved in one or more implementations could, and they would serve Nostr better.
• GitHub might have been a good platform for a while, but it's becoming increasingly worse in many aspects. And for the discussion forums it provides (the "pull request" and "issue" pages) we should be dogfooding Nostr-based groups or even kind:1 threads. We may keep the registry of kinds there for now, but since that is just a simple list it will be much easier to move elsewhere later.
• There are already many practices out there that aren't codified in the NIPs repository, and it feels wrong that some (including some that I personally disagree with) have this inevitable officialness aura that comes from the NIP number while others that are pretty good don't, just because they are only being used by one person.
• As the NIPs repo inevitably gets more ossified we'll still need a way to assign the remaining kind numbers to the hundreds of unexplored Nostr possibilities. This approach hopefully serves that.
• And, finally, this flexibler approach allows bad or abandoned NIPs to effectively die such that they don't continue to pollute the minds of every new programmer that first gets introduced to Nostr and inevitably starts reading the "list of NIPs".

One last irrelevant word, if you aren't tired of reading: when I first turned the LNURL spec from a single confusing blob of text into a modular numbered-documents approach that approach felt very correct. However the situation was different, that thing described a single main "flow" with strictly optional features on top, each document described one of these optional features and what dependencies they had. Then I just copied that approach to Nostr, I'm not sure if I thought Nostr was always going to be a single main flow (text notes) but it clearly isn't and hopefully it will grow to be even less like that. Nostr also clearly isn't like a single-implementation programming-language-spec with a dictator and his committee on evaluating random "improvement proposals". So we're forced to conclude that the numberered-documents approach isn't the best way to do coordinate the creation of Nostr-based sub-protocols.