Nips should just be long form articles, they should be "endorsed" , not be approved.
The centralization of the nips repo is dangerous. Nips can easily just be managed on nostr itself. Its a shame we've not done this yet.
Login to reply
Replies (30)
@verbiricha if we add an endorsement feature to habla. We can just filter all long form articles tagged "NIP" and sort them by endorsements accordng to WoT.
They are on 
and also on wiki if you want, the fact that you don't know about this is precisely the positive fact of the NIPs repo, the other one you don't even know exists
NostrHub
NostrHub | Discover and Publish NIPs
Explore official NIPs and publish your own custom NIPs on NostrHub.
I knew about it wasnt sure if it had the endorsement festure already, but ideally all long form clients could incorporate it
Also the fact that it has an "official" tag itself is cringe.
the official NIPs are correct
What does correctness even mean? DVM and NIP-4 are correct. Just because a dev overlord said so?
They are on the list, then whether they are good or bad just read them
Why call it official? Who has the authority to csll them official? Why? How? Why should it matter?
Or wikis, they could work too. But we do need an endorsement mechanism for social signalling
Syncing is stupid. There doesn't need to be a source of truth as all, endorsements are for gauging rough consensus which is all that is needed, that GitHub repository needs to die.
We already have kinds for long form.articles or wikis which could be reused.
I dont understand the sync issue you refer too, we have many, and how it affects this particular problem.
Ahh this is the problem and the paradigm shift with nostr. There is no authoritative record. The GitHub repository is treated as such but im arguing that it shouldn't be. Even NIP-01 isnt necessary in its entirety to be interoperable the only thing necessary is following libsecp56k1 for key derivations and signatures.
The fact that the GitHub repository is exist and as dogmatic as it is, is intact a problem.
The sync issue sbouldnt have happened at all, because there should have been no reason to sync at all.
Im sure this is not the first and last nip to be shadowbanned by bureaucracy.
But it did help me understand that none of my nips should ever touch this repository.
Not being strawmanned at all. I really do mean it, all of the rest really is just strung together ideas of what can work to achieve your goals.
Goals that can be different for different people, need to true censorship resistance? Use gossip.
Need media servers with nostr identities? Use blossom.
Need http auth? Use nip-98 or whatever it is.
This is what makes nostr special, the fact that it can be stripped to its bare necessities.
Also you've established that its not your circus, I dont mean to pull you in, just stating the facts as they appear.
Libsecp256k1k is at the heart. Use it and you get the reusable ideaBritt. Event structure is the next most basic part, use this and you get 80% of the interoperability, add websockets and it is the protocol as we see it today.
they haven't found interoperability
Ideabritt=idnentity*
I laid it out, I cant help it if they're blind.
I dont blame them for being blind either. Just laying out that this model for specs does not align with the ethos of this protocol.
maybe if they can't do it, I doubt there is anyone more capable, yours is probably a broader protocol that needs more specifications to work
No one needs to approve specs. Thats the fault in thinking, people just need to endorse it, and whoever needs it can try it for themselves, im not doubting their capabilities, just that this is not how nips are meant to be treated.
NIPs are nostr implementation possibilities. You cant gatekeep what is possible.
That's why I love the NIP NIP by @npub19raz...923v:
NostrHub
NostrHub | Discover and Publish NIPs
Explore official NIPs and publish your own custom NIPs on NostrHub.
The only thing i dislike here is calling them "community" nips, as if the github nips are in some way superior.
There are many examples of NIPs that went beyond the repo, the same DVM had the same repo, NIP-99, NIP-EE, Clink 
and so on
GitHub
GitHub - shocknet/CLINK: Common Lightning Interface for Nostr Keys
Common Lightning Interface for Nostr Keys. Contribute to shocknet/CLINK development by creating an account on GitHub.
💯 agree.
We are the repo now.
See the comments ...
Exactly, then what is the point of this permissioned PoS?