On the NIP repo

[SilberWitch]

Problems I am seeing

1. The NIP repo is too static to cover all major/popular events or implementations. Even just changing the README to include some more hyperlinks takes days because of the fixed management overhead of a git repo.
2. There has been little take-up of the NUDs idea, as people prefer to just curate the wiki list or the repo README, as it's faster and has higher visibility. But this reduces the potential for use cases involving the NUD events, such as referencing them from apps and auto-generating a compliance document from that.
3. Some Nostr devs are avoiding GitHub, for moral or practical reasons, and I suspect that will grow, as the Nostr git products advance, FOSS developers come under tighter regulation and observance (like the EU is contemplating), and GitHub tightens the screws further on small-time devs.
4. But we now have two different lists for the same information, which is inefficient, redundant, bad data management. Both lists are manually-curated, which means they're going to tend to be inaccurate or outdated. And there is a bifurcation of the source data for the NIP-potential specs, between the wiki and the NIP PRs.

I am therefore suggesting that

1. We move the event list entirely out of the README and into a separate file.
2. We request all potential NIP authors publish a NUD. (Perhaps the repo owners could publish a NUD for the current NIPs, to make everything backward-compatible.)
3. We include a tag or something for a list of event kinds described in the NUD, if any.
4. We use a Nostr query to auto-generate a list of NUDs and their respective events, and mark the ones that are NIPS, with a hyperlink to the git repo. Then we could sort or filter the list by NUD, NIP, or event kind.
5. We save this list in the repo, after controlling the content for spam or whatnot, and update a wiki page with the content of that quality-checked list.

Fazit

This would mean that the repo owners control the list, but not necessarily the content or actualization of the list. They're more list curators.

It would also mean that NIPs are "generally relevant NUDs", that the repo owners curate; promoting or demoting NIPs, as they become more or less useful, but without deleting anyone's NUD or needing them to suggest the spec be added. PRs in the repo would therefore be limited to repo owners, who suggest items on the NUD list to be promoted or demoted to NIPs. NUD specs are stored outside of this repo.

It also means that no new concept needs a NIP identifier. It has a NUD identifier and would be given whichever number is available, when promoted to a NIP.

[staab]

I appreciate this proposal, it's balanced and practical. I think the main thing missing to make this work is a client that can allow users to browse NUDs and lists of NUDs (which could be relativistic as well, there's no reason multiple groups couldn't curate NIPs too). Wikifreedia is a fine proof of concept, but it's not really there yet (hard to browse, find consistent results, my NUD text got mangled when I edited it). It's also more diffuse content-wise than the github repository, which would make it harder for new devs to get started. I'd like to see a FOSS NIPs client that supports this. It really wouldn't take much, and could easily be a fork of wikifreedia, but I think it's a necessary condition to getting this done.

[SilberWitch]

That's why our team switched to wikistr and we're going to host an instance of it. It's the only wiki client with effective search and where we could reliably point to particular versions of an event.

I agree that this could easily be the basis for a specialized NUD browsing client. The content of the NIP repo could also be included in the client, so that you can use it as a sort of protocol reference client. It could also include the issues and proposals from Nostr, and chats and highlights about particular NUDs/NIPs, that the repo owners could peruse.

I think we also need lower noise in the NIP repo. The signal is getting watered down with all of the PRs. A NIP PR should be sort of exciting, so that it's Nostr News that draws attention, and the repo owners can throughput faster because one of them has already prepared it according to their repo standard practice.

We heard about NUDs from you and I've looked at the spec a few times, but the problem with dual manual lists finally made it "click" for me.

[SilberWitch]

I think this PR thread and the NUD thread and our own conversations hint that this is maybe the way to go.

[SilberWitch]

Should I just issue NUDs for everything on the list and then compile the list on the wiki from the query and resubmit it to the repo? Just to get the ball rolling, I mean.

[sroertgen]

get that ball rolling