Should this repo stop accepting new NIP PRs?

[arthurfranca]

Not my idea but makes sense.

nips repo should be compilation of the protocol specs people make not the thing they try to make their systems compliant with
source

IMHO applications that run on top of nostr should be referenced by the NIPs repo and have their kind numbers registered. But they shouldn't be defined in the NIPs repo. We've been doing this wrong all along [...]
source

Maybe Pull Requests from now on should be just requests of additions to the event kinds list from app creators.

And issues should be the place for inviting interested people to discuss new NIPs elsewhere.

[staab]

This has always been an option, but few people have taken advantage of it. I don't mind the idea, but who is going to refactor the whole repo and/or maintain contributing specs after they're adopted? Maybe I'll start moving all my PRs to a third-party repository and PR only new kinds to try this out.

[mikedilger]

Anything that augments the protocol (NIP-50) or is usable by many apps (NIP-05) even if outside of the protocol should be here. But IMHO (I'm the 2nd source) apps that just run on top of nostr and need a kind number allocated, they can be elsewhere. But we should link to them from here.

But like @staab says, I'm not keen to do any refactoring. It's just my idealistic preference.

[kehiy]

#995 (comment)

#1710 (comment)

i've discussed it before. but based on the last discussion with @vitorpamplona on github the name of this repo and NIPs word, we can't say those application-specific standards are not NIPs.

but i prefer them to not be in this repo. also, it gives more freedom to developers and makes it more decentralized. since merging and changing stuff on this is kind of fully centralized. in that way, at least application specs are controlled by different people who are actively implementing them, and someone may fork them as well.