who’s got complete authority? that’s not correct.

Reply to this note

Please Login to reply.

Discussion

Course it is. All the authors to all the NIPs were removed in 12 hours. 12 hours! There was no consent. There were several objections. One entity has complete control.

Can you give more context? What happened?

Looks like a couple of days ago nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 reorganized the GitHub org and team for nostr-protocol. Is this what you’re talking about? I see 19 people in the team as having commit access.

I spent years in and around the Ruby on Rails community. They eventually developed rails-core which had a process for joining and leaving. While a protocol is different from a framework, this feels broadly similar. Rails wasn’t perfectly managed but it has worked for almost 20 years and handled a bunch of conflicts while staying open. Nostr feels broadly similar.

He’s talking about the fact nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 removed the authors tags from the NIPS and how he went about doing it.

FWIW, I don’t think the NIPs should have owners or authorities so asking for consent to remove the attribution doesn’t make sense as the people who wrote them were never the owners (it’s stated as “public domain” after all)

Do what works for you, but dont remove the authorship from the work of others, without consent. And certainly not in 12 hours. That is not an open process.

I think Melvin may be too used to the W3C world where the spec is the only thing that matters and people write tons of specs and then 99% of them are never implemented but they still talk about the specs and spec authors with religious respect and ceremony -- so he thinks the NIPs repo is a very powerful entity.

In fact the NIPs repo is constantly running behind implementations and trying to stay relevant in a chaotic scenario of 32 different clients each with their own priorities.

You may be putting too much weight on the nips repo. If it was shut down today nostr would be fine, another repo fork would replace it.

One entity has complete control over that repo, but that doesn’t define nostr, it has at most a big influence, which can be lost if it no longer reflects what is implemented in clients and relays.

Nostr is defined by NIP-01, it has changed before, it will change again. That's guaranteed.

It is no longer defined by NIP-01, it is described by NIP-01, changing NIP-01 does not automatically change the code in clients and relays.

Let me try to change NIP-01 and you watch the Nostur codebase in your computer to see if it reacts.

This would save me so much time!