That being said even if the NIPs repository is centralised it has no way to enforce bad decisions in a tyrannical way. Client devs are "free farmers" and can do whatever they want but it is in their best interest to follow the interoperability train most of the time. The users keep client devs in check.
A centralised NIPs repository is not a bad thing.
quotingI think there is a fundamental contradiction in the idea of decentralizing the nostr NIPs. If it were truly decentralized we would have multiple NIPs repositories that did not agree. A protocol doesn't work well when there are different variations on the different NIPs. As much as it is anthetical to our very natures, I think it has to be centralized and that we have to fall in line as subservient to the people with merge access. At least it is not a govenment, it is just a protocol specification. And at least it isn't just one person, it is many. And clearly they don't like this state of affairs either but there is nothing to be done about it. Seriously I see no way to truly decentralize it without a long period of nostr-wars where clients and relays only become "eventually compatible" based on what people actually code, and things that happen that way tend to accumulate crap over time (not that nostr doesn't have it's share of accumulated crap for other reasons).
nevent1q…7t7v
It's great to have a decentralization ideal. But sometimes for practical reasons ideals cannot be achieved and pragmatism needs to overrule. And we cannot all have merge access.
I had merge access once but I revoked my own permissions. Then I got them back somehow. Then they went away again somehow. Generally I wasn't using them because I don't want the responsibility. It's fine to complain about a merge you don't like, but anybody who wants merge access automatically becomes suspicious in my book.