Decentralizing the NIPs registry

[fiatjaf]

Would be great if people could agree on NIPs and publish them on Nostr itself, without having to request permission from a cabal of maintainers of a specific GitHub repository.

Then people could see NIP proposals and say they endorse them or not, or point to implemented NIPs by their ids from client and relay implementations.

This could be chaotic at the beginning but I think it would be healthier to the protocol. It would also be nice to not lend all the NIPs an equal status of "officialness" just by them being in this repository.

The sad thing would be that we would lose the cool-sounding NIP numbers.

[fiatjaf]

To be honest there are some NIP proposals that I don't like at all and don't want to merge, and while I try to say to myself that I should merge them if there are some people wanting them and they're not completely absurd, I feel like when merging I immediately award them with a special status when they shouldn't have that -- no NIPs should.

Moving this to a permissionless place would fix these two issues.

[tmathews]

I agree, developers should feel free to experiment and try things. They can release their own NIP for what they have created and if it catches on great. The repo/pr/issue process is acting as a gateway rather than a documentation.

[andrerfneves]

Yes to this. Make NIPs great again

[mikedilger]

I'm worried.

I get the argument @fiatjaf that you don't want to be gatekeeper and don't want to be seen as blessing these NIPs. But I think if we don't have some kind of partial consensus or partial centralization, interoperablity will be at risk.

So long as whatever replaces this serves the purpose of extending nostr and also allows us to continue to be interoperable, then my concerns are addressed.

[ghost]

Concept ACK

Bitcoin developers tried doing it but failed although some proposals for Bitcoin exist outside https://github.com/bitcoin/bips repository and implemented in different projects.

Related emails

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018869.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018871.html

Would be a great if nostr protocol has no official registry for NIPs however proposals still get discussed. Instead of NIP numbers, developers can use present year and a unique name for it. Example: NIP 2023-Ostrich

[eskema]

developers can use present year and a unique name for it

we'll need a decentralized name registry first then.. because who decides what unique name is the right one? maybe a note id would make it unique, and we can petname it?

why not a nip kind?

[fiatjaf]

Yes, I agree, an event id is probably better.

I was thinking that just having a "long form editable text" kind would be enough, then we can use that to write NIPs.

[cameri]

Could we use parameterized replaceable events? We just need a client that supports editing and then the conversation can happen on Nostr.

[fiatjaf]

I was thinking of doing editable texts using parameterized replaceable events, like this:

kind 10 -> article title
kind 11 with `d` tag pointing to article title -> article body that can change

The problem is that this will not allow anyone to refer to an old version of a NIP.

[cameri]

I was thinking of doing editable texts using parameterized replaceable events, like this:

kind 10 -> article title

kind 11 with `d` tag pointing to article title -> article body that can change

The problem is that this will not allow anyone to refer to an old version of a NIP.

I was thinking along the same lines.

Not sure if we need kind 10, could just be a kind 1?. The article body kind should be in the 30k to 40k range and the d tag could be the event ID of the kind 1 post like how the channel metadata event works.

People could comment on the article and suggest improvements w/ patches as git diffs?

[fiatjaf]

Right, yes, sorry, I didn't read the NIP before commenting.

I don't think it should be a kind 1 as that will cause these things to show up in social clients feeds and make not very much sense. I think they require special clients (or special support in normal clients), therefore a new kind is better.

But I am thinking this new kind could be used for all sorts of "articles" and to make kind of a medium.com alternative on Nostr, and maybe a Wikipedia alternative on Nostr, not only NIPs, NIPs would be just one immediate use case.

I do however feel sad for not having the ability to reference old versions. If I say I implement and like one specific NIP and then the author changes that completely, where do I stand?

[chakany]

We could always store the old content inside of a h tag organized by timestamp

Either that or there could be a new kind of replaceable events that has a history feature. Relays serve the newest one by the tag but if a client want the older ones it has to ask for it

[cameri]

I don't think it should be a kind 1 as that will cause these things to show up in social clients feeds and make not very much sense. I think they require special clients (or special support in normal clients), therefore a new kind is better.

Yup. Makes sense.

I do however feel sad for not having the ability to reference old versions. If I say I implement and like one specific NIP and then the author changes that completely, where do I stand?

You are right, replaceable events are not good for this, the history (commits) is important.

I think kind 10 is fine for starting a new article, and the event ID is the foundational event for anything that follows. I still think we would need a kind 11 to change the metadata on kind 10. So far metadata can be: title, state (draft, final, etc), authors/editors.

We could have forks so perhaps kind 10 can reference a previous kind 10 event.

It almost feels like we'd be recreating git IMO with the only difference that you'd be using your Nostr key instead of GPG for signing.

[fiatjaf]

But for these other use cases no one cares about the versioning, so it would be unnecessary bloat and make queries huge for basically no reason.

[fiatjaf]

The best solution I can think of now is for somewhere a client or a relay specialized in storage to keep track of the specific versions someone ask them to keep, so they can be referenced or restored/forked if overwritten.

[gkbrk]

Once published, it makes sense to not be able to update decentralized NIPs, and instead refer to them by their event IDs. If a relay advertises support for a NIP, and later the author updates the contents of the document, the relay might no longer be supporting that NIP.

Similarly, if someone reviews a NIP and tells others it looks good, and then the author updates it and makes it not good, people doing the review will need to retract their comments and warn everyone else that the NIP changed.

If it can be updated, deploying or reviewing a NIP not only has an initial cost, but an ongoing cost until the end of time because you can never know when a NIP will be updated. You always need to check and do work to keep on top of everything.

[gkbrk]

kind 11 with d tag pointing to article title -> article body that can change

The problem is that this will not allow anyone to refer to an old version of a NIP.

People can still refer to the older versions by the event ID. Replaceable events don't invalidate existing events, just replaces them for a pubkey-kind-tag.

[melvincarvalho]

So I think at this early stage there's a need to prevent collisions:

I very quickly made this:

• json for kinds
• Live JSON

Completely unofficial, of course. I have no idea if it will be useful or get upstream, but I'll try and keep the list up to date if people add kind numbers.

Or just take it and put it somewhere in nostr-protocol if desired.

[mikedilger]

@melvincarvalho I recently dug through all the PRs to extract all the kinds that might be in use and came up with this list, above and beyond what has been merged it:

6 - repost (? closed) 8 - bookmarks (NIP-29) 8 - poll & vote (NIP-41) 8 - badges (NIP-58) 9 - resource (NIP-30) 12 - decoy key proof (NIP-24) 17 - git updates and discovery (NIP-17) 30 - chess game event 32 - reputation (NIP-32) 104 - encrypted group chat (NIP-38) 140 - encrypted group chat (NIP-38) 141 - encrypted group chat (NIP-38) 142 - encrypted group chat (NIP-38) 143-149 - encrypted group chat (NIP-38) 4326 - geospatial note (NIP-44) 9374 - lightning zap request (NIP-57) 9375 - lightning zap invoice receipts (NIP-57) 9400 - web-of-trust reputation (PR #203) 10000 - nostr dns 10001 - (NIP-23 closed) 24133 - nostr connect 30000-30002 lists (NIP-51) 30008 - badges (NIP-58) 30023 - long form content 30303 - relay status (NIP-59)

[melvincarvalho]

Work in progress, a little html page that will display NIP numbers from JSON

https://nostrdata.github.io/kinds/

[melvincarvalho]

Two very good resources here:

• https://nips.be/search
• https://nips.be/nips-info.json

[earonesty]

I like the idea that people can vote for nips just by clicking the like button!

[marcusmmmz]

How would event kinds be assigned? Ideally that would be with a uuid/event id, since then anyone could create their own NIP + the needed event kinds and there would be no collisions (and kind collisions are a bigger problem than NIP collisions). Would that even be possible, considering that kinds are currently represented by numbers?

Having a mostly "blessed" source of -IPs is not a problem generally, Bitcoin for example does just fine having BIPs this way, But Nostr is different because Nostr clients and relays always have the option to not implement a NIP (so it's not like Bitcoin, in which global consensus is needed for a change).

I think the workflow for Nostr should happen in a manner in which it's possible for clients to start innovating alone, NIPs and event kinds being created by them, and later if that functionality is seen to be done in a good way it could be "blessed" just at it is today, and by being blessed i mean recommending that this NIP be used instead of creating a new one. This way there would be a balance between innovation and interoperability.

Either way, what is the expected workflow nowadays? How would I go about choosing an event kind for a new functionality that no other client currently has? Am I expected to actually wait for an event kind to be assigned by the Nostr team before I can start using it?

[Giszmo]

I wrote an article on this topic here. The key take-aways would be:

• pet names: If Alice calls it nip999, people can reference it as Alice.nip999
• endorsements: If Bob endorses Alice.nip999, Bob.nip999 is the same nip but Carol can also endorse EventId as nip999. For endorsements I suggest an n-tag.
• we need something beyond nip33 to make sure Alice:KindNip:999 returns just one event but as Carol kept the EventId around, it can also be found with an extra round-trip
• In practice, some relays already keep old versions of nip33 events around but it makes sense to make it explicit for this use.

[Giszmo]

Proposing #400 to overcome event deletion. Proposed NIP also contains how a nip registry could work.

Edit:

Concerns expressed above are

• fiatjaf doesn't want to be the gate keeper. Even with GitHub, he isn't really. If people really disliked what he did, they could already abandon this repo for another. If people want to spec something out, they can.
• We would lose the catchy nip numbers: As a group could define a new nip-1 and follow that over "ours", in my proposal there would be a fiatjaf.nip1 but giszmo.nip1 could differ. Many would probably endorse fiatjaf's nips but just like with github that wouldn't force hands. Once we abandoned GitHub for nips, nip numbers would work just the same.
• Versioning would cause bloat: Yes, the proposed nip taken at face value would also generate bloat but relays are not forced to keep all versions around and would know which ones are endorsed and which ones not. With endorsements of "fiatjaf's nips", one would not lock up all older versions but some could. With major changes, nip authors could reference the prior version via the event ID themselves in the "replacing" version but that would probably rarely be used.

[ghost]

Decentralizing the NIPs registry

It would be interesting to write NIPS here: fostr.dev

[telamon]

Nice, this is a pretty rad idea. I did't read all of it. But why not do git push to a relay? I used a git push helper once to push commits into a hypercore. And SSB I think had something similar.

You'll need some sort of ux to discover/track the forks, but a "gitstr" would potentially decentralize not only nostr governance but also impact other repos or the way we treat free/open source.

[melvincarvalho]

Almost a year on from this we dont have an alternate workflow, let alone a decentralized one.

It might not be the case, but casual observation of the NIPs area is that it's turned into a dictatorship. Some NIPs if authored by certain people would get prioritized. Others rejected on principle.

That is maybe as it should be, since open source is always a web of trust. However it relies on a super human benevolent dictator. And we certainly dont have that.

Let's propose something better and practical.

Another stream for nips with another workflow.

This NIP repo handles NIPS 1-1000, and they are the core NIPs that are 'official'.

We need an area for 'unoffical' NIPs. Why dont we allocate numbers 1001-2000 for them, for the time being so that they dont clash. NIPs rejected from the official NIP repo can be marked experimental and go to the unofficial NIP area. By going from NIP-XXX -> NIP-2XXX

NIPs that are very good in the unofficial can be taken up as an official 2xxx NIP. And so on.

Developers get to choose their NIP area and workflow. Something like that ... thoughts?

[Giszmo]

I think we shouldn't take this repo too serious. If your idea has merit, write a nostr long form post about it and implement it in your client. Screw our dictator (fiatjaf we love you ;) ) If the idea is good and others want to interoperate, they will implement it regardless whether a number was assigned. "Melvin's DM scheme" is as good a name as any other. What is it with the drive to have something "official". There is no concept of "official" in a decentralized system.

Also I think it's getting a bit out of hands here anyway. Many nips don't follow the rule that it has to be implemented first by two clients before it gets to be a nip.

[vitorpamplona]

I agree with @Giszmo. Do you want to describe your NIP somewhere else? Sure! Go for it.

Anyone can create a NIP repo anywhere. But NIPs are useless by themselves. They are only valuable when they accurately describe an actual implementation that has been shipped AND is doing well. And I think there is no real use (2+clients) of Nostr that have been blocked from publishing their NIPs here.

There are no official specs. There is only a bunch of devs trying to make their stuff more understandable to others. And for that this repo has been great.

[AsaiToshiya]

As #867 informs, kind is more important than NIP to avoid breaking each other.

[gsovereignty]

We don't need to roll out a complete and final solution all at once, we can take very small steps in a direction that isn't wrong, and see what works and what doesn't.

Instead of this repo being a central planning commission that sanctions and gates access to development on nostr on behalf of Jack (I'm not saying it is, just that it's perceived that way by people discovering the project for the first time, which sets the tone), it could instead be a reliable resource for NIPs that exist anywhere in the wild.

As soon as a Kind number is actively in use, it MAY be added to the index in this repo, along with a link to a NIP (on github, as an event, or anywhere else). The bar for this should be VERY low.

The role of the central planning bureau is then to signal their opinion on the current status of the NIP by incrementing its lifecycle status. This converts the honourable members of the politburo from leaders into advisors.

In any case, the smallest possible step we can take right now in that direction is to tolerate NIPs existing outside of this repository. The question I have is whether this direction is possible, so I've created a very small PR #867 as a litmus test to answer that question.

I think we shouldn't take this repo too serious.

We don't control how seriously people take it. To the vast majority, and certainly to anyone new, this repo is the authority on what is allowed to be done on nostr.

This was not the case in the past, and if nothing changes then the ossification will continue, with predictable and counter-revolutionary results.

[erskingardner]

I agree with @Giszmo and @vitorpamplona I don't think we need to have a formally defined separate repo. If you want to create something, go for it. That's permissionlessness. I have yet to see any net new NIPs that don't have at least 1 implementation get built, usually there are two, often more than that.

The idea that the NIPs repo is a dictatorship is abdicating the personal responsibility to

1. clearly describe what your new NIP matters,
2. build consensus/acceptance with peers, and
3. build/beg/borrow/steal to get the new thing implemented in 2 clients.

The only NIPs PRs that I see wallowing fail at one or more of these and so deserve to wallow until they improve.

Also – @fiatjaf isn't the only person with merge rights, so it's more of a council of priests than a dictatorship. 😂

[melvincarvalho]

isn't the only person with merge rights

But that is not transparent to the public. It needs to be to attract developers. It's something that's not obvious to those with merge access, but very obvious to 99% that come to the repo.

Lack of transparency and bike shedding are generally regarded as the biggest 2 killers of open source.

[melvincarvalho]

We don't control how seriously people take it.

It misses the point. That the whole thing is shrouded in mystery and centralization means that people wont even start or try. They will go elsewhere.

People do take it seriously because there's no other place to put NIPs, to name NIPs, to get NIPs reviewed, and to coordinate, which is vital in this stage of the project.

If it's seen as gate kept, and it is seen that way now, development will go elsewhere. Simple project hygiene that all our competitord do, such as activitypub sees them gain developers who could be building on nostr. Agree that it doesnt all need be solved in one go. But the impression is of a dictatorship, and if it isnt, it should be easy to demonstrate.

Why not show the world who has commit access? What is there to hide?

[erskingardner]

Why not show the world who has commit access? What is there to hide?

Yeah, I agree, the NIPs repo should have a readme or another wiki doc that explains how the NIP repo works, including who has merge rights, and why. Sounds like we have more of a marketing/documentation issue here rather than a procedural issue in how new NIPs are created/merged.

[melvincarvalho]

This thread started out as a call to decentralize the the nostr core working process. Good idea.

It's now revealed that the current process is a "council of priests" operating in a closed centralized way, that wont even reveal to the public who they are.

No other open project does this. Why not reveal yourselves on the github people page? It looks dystopian af. Why is there any resistance at all to being open?

So why not just tell the community who is the council of priests.

[staab]

Why is there any resistance at all to being open?

I don't think there's any resistance, there's just apathy. I personally never use my merge access (hello, you may refer to me as "perfect elu kadosh hodlbod"), and when I do I regret it because I end up being too hasty. Nostr is a high-trust society, no one has abused their merge access (that I've seen). So sure, if it'll make people feel better let's list the maintainers somewhere.

[AsaiToshiya]

It's now revealed that the current process is a "council of priests" operating in a closed centralized way, that wont even reveal to the public who they are.

I don't think so because the acceptance criteria for NIPs are clear. It's just that the interest of the maintainers are a little biased.

[jb55]

On Wed, Nov 15, 2023 at 02:31:47PM -0800, Melvin Carvalho wrote:

This thread started out as a call to decentralize the the nostr core working process. Good idea.

It's now revealed that the current process is a "council of priests" operating in a closed centralized way, that wont even reveal to the public who they are.

No other open project does this. Why not reveal yourselves on the [github people] page? It looks dystopian af. Why is there any resistance at all to being open?

Is there? Who is resisting? If anyone is resisting to this I don't want to be a part of it.

So why not just tell the community who is the council of priests.

current list is

@atdixon @BrightonBTC @Cameri @eskema @fiatjaf @Giszmo @jb55 @KoalaSat @mmalmi @monlovesmango @ottman @pablof7z

[staab]

Hey, what about me

[jb55]

I was just listing people from the https://github.com/orgs/nostr-protocol/people page like @melvincarvalho mentioned. maybe you're specifically on the nips repo?

[staab]

Yeah, I think most people probably are? @Giszmo is the only one publicly visible on the org

[Giszmo]

I would suggest to make it a requirement for members to be public. @jb55 did what I was tempted to do - share the list without asking.

How about removing all members that do not set their membership to "public" by end of next week?

I don't particularly care about being a member as I did not use that privilege in months and removing unused privileges is a good security habit anyway but I do care about members being public.

I know https://github.com/orgs/nostr-protocol/people but I fail to find members of https://github.com/nostr-protocol/nips

[staab]

Ok, so I've looked and I don't know how to set my visibility as public.

[fiatjaf]

I've just invited everybody who was in the nips repo to the nostr-protocol group. Please make your membership status public so you can become targets of the State.

[staab]

Behold, the priests reveal themselves in their shining spotless garments, to bring down the oracles of heaven for the mere mob that waits with bated breath to be told how they might speak with one another. Their fears are quelled, doubts stilled, the earth runneth with fat and honey, mothers give birth without pain, and all is well.

@melvincarvalho, I really don't appreciate how you forced this issue. You could have brought this forward in a cooperative fashion. Instead, you chose to sow doubt among nostr plebs instead.

I hope you understand that you're the only one acting in bad faith here.

[jb55]

Ok, so I've looked and I don't know how to set my visibility as public.

I don't either, I didn't even know it was private

[pablof7z]

Yeah, it's very hidden, I also had to look to reveal myself:

https://github.com/orgs/nostr-protocol/people

[pablof7z]

current users who still have it as private:

@alexgleason @atdixon @BrightonBTC @Cameri @eskema @jb55 @mmalmi @ottman @Semisol @verbiricha