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.

[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)

[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

[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

[staab]

Maybe a CONTRIBUTORS file would be a better way to do this. #883 (comment)

[vitorpamplona]

Contributors with npubs, not with GitHub users.

[fiatjaf]

I think a CONTRIBUTORS file solves nothing, and having merge powers isn't the same thing as "contributing".

[staab]

What I meant was to have multiple sections. I.e. "owners" "merge-access" and "contributors". This would certainly get out of date but at least people could send PRs to it if they want their name on something.

[alexgleason]

You can get a list of contributors from the repo and display it however you want. Let me show you a thing I created in Next.js. On the Soapbox website, we pull the top contributors from GitLab in the past 30 days, and display the top 4 contributors with their avatars. Then in the background, we display an activity graph of commits over time:

https://soapbox.pub/

This is related to #883. I want people to realize that git already has all that information, information is not lost, and that it's just a matter of displaying it on a webpage if we want to do so. GitHub simply doesn't choose to prominently display it somewhere on GitHub itself, but we can still display it somewhere.

I used the GitLab API for my project, but you could use GitHub API, or even clone the repo locally and use git itself. I use a scheduled CI to rebuild the site every night; point is, it can all be automated.

If we decentralize NIPs, then author information would be available on Nostr itself, and it would be possible to do the exact same thing.

[staab]

@alexgleason I told Melvin this and he ignored me. I do think it's a bad idea to couple everything to github though.

[fiatjaf]

Honestly this obsession with knowing who has merge access is counterproductive and paranoic. The list has no meaning, it can be changed anytime by me and the repository history can be rewritten.

[Giszmo]

The obsession with knowing who has merge access goes to show which importance some attribute to this repository which would be a non-issue if we had a decentralized NIP registry.

Maybe it is paranoic but paranoid people will make noise and paranoid people are certainly over-represented among those worried about censorship and free speech.

The list has meaning to some or we wouldn't be talking about it.

Yes, you can change it as the repo owner. So what?

The history can be rewritten but not without being very much detectable. The repo was cloned to a thousand machines that would all notice the change.

So why not either kick those who don't want to be public or agree on it being totally ok to do what jb55 already did anyway and share the list of all whenever anybody asks for it?

[fiatjaf]

I don't disagree with that at all. I'm all for sharing the list, and I had done it multiple times before, including once to Melvin like a month ago when he complained about it on the Telegram group. He remains the only person complaining about this as far as I know.

I agree to kick everybody who don't set themselves to public on the organization.

[weex]

Added the PR above because I think there's something nice about the list being explicit and managed via git. If someone wants to join or leave they submit a PR. Not sure this issue is solvable in the classic sense but this can be progress.

[pablof7z]

I think having an explicit list of maintainers in a file makes it worse, if anything, I think @vitorpamplona 's autogenerated image is better as it's implied that it's generated from git activity, but an explicit file is weird.

Overall I think this whole thing is a non-problem.

[weex]

61 comments over 10 months doesn't seem like a non-problem, but in long meandering issues like this it's easy to oversimplify.

In this issue we have the following problems mentioned:

• the need to request permission from a cabal of maintainers (fiatjaf)
• this repo grants special status to documents which are merged (fiatjaf)
• interoperability could be at risk (mikedilger)
• NIP id uniqueness (eskema)
• ability to refer to old versions of NIPs (fiatjaf)
• NIPs as kind:1 notes would clutter up feeds (fiatjaf)
• kind collisions (melvincarvalho)
• "blessed" IDs are an unnecessary constraint in a system that doesn't require consensus (marcusmmmz)
• the NIPs area has turned into a dictatorship without a super human benevolent dictator (melvincarvalho)
• NIPs don't follow the two implementations rule (giszmo)
• this repo is seen as the authority to newcomers which will lead to ossification (gazhayes)
• merge access isn't transparent which is obvious to new developers (melvincarvalho)
• there is no doc that explains how the NIP repo works, including who has merge rights, and why (erskingardner)
• the interest[s] of the maintainers are a little biased (asaitoshiya)
• github visibility controls are very hidden (pablof7z)
• this obsession with knowing who has merge access is counterproductive and paranoic (fiatjaf)

When I get some time I'll break this out or link in a handful of issues to do with the mechanics of decentralizing the protocol and others to do with managing this github repo. Then it'd probably be a good idea to close this issue. My 2 cents as a pleb.

[telamon]

@weex thank you for the summary.
The problem in it's simplicity is that you can't decentralize a git repo using centralized tools.
And some of the tools required to decentralize are currently being designed within this repo.

It's a non-problem that becomes a problem only IF you attempt to solve it - my cent:
Let it go, be kind, have fun.
:'-)

[decentropy]

Re-imagining NIPs is a neat idea... I actually stumbled across this issue, because I think some NIPS are not flushed out (e.g. user statuses) & don't really know where to discuss.

First... I don't think there should be NIP #s.
I think docs/comments should be organized by Event Kind #. (Why make people remember two sets of numbers?)

I sometimes use https://nostrapp.link to look up event kind, and see what apps use them.
I think a site like this, that adds discussion and (somehow) allows updateable wiki-like documentation would be great.
The rule of thumb, requiring 2 or more apps before a feature is considered "accepted" seems good... but a place to draft & discuss new feature prototypes & ideas makes sense.

Not sure how the decentralized wiki could work...
I think you need some list of maintainers/approvers somehow.

[marcodpt]

NIPs must be centralized, but instead of following the opinion of leaders or good ideas from the community, the repository must have the philosophy of documenting market practices.

So the people involved in the repository must be characteristic of researching what relay and app implementations are doing, and only when a practice is very successful or a market standard be documented.

This is exactly how Roman law (the most successful case of private legislation in history) worked.

And this is how the first and only decentralized social network should proceed.

Nothing prevents good implementation ideas from being disseminated through blogs and forums (inside and outside the nostr), but NIPs should only be the established market standard.

First you create the software and then you document what worked.

Talk is cheap, show me the code

[fiatjaf]

That's one of the goals of this repo: to document what is being done.

But also having a discussion with other interested people before you conclude your implementation is also a healthy practice otherwise people will implement the same thing in multiple ways and whoever has the most popular implementation will always win even if their implementation could have been much improved by just talking a little bit with others with open mind and vice-versa. If everybody is happy and have their voice heard and their opinions considered that gives a much stronger basis for a nice interoperable protocol. Providing such a discussion space has been another goal of this repo -- although having the discussion happen somewhere else more nostric would be better, we still don't have that place.

[marcodpt]

I read what was written in the repository's objectives, and I almost completely agree.

What I think is that if the proposals were discussed in a draft environment, and implemented by interested relays and apps and only after a certain market success were documented in the NIPs, it would greatly reduce any problems of backward compatibility or depracated NIPs.

But anyway I would like to thank the community for the wonderful work and in my view the protocol is the king and nostr has been the winner since NIP 01

[marcodpt]

In my personal opinion, git is better for persisting data like a book or documentation, so nothing beats having this material written and, if necessary, replicated on several git hosts.

But nostr is infinitely better for creating a community, something like a slack based on nostr would be a very good app for discussions, topics and proposals through a community that cannot be destroyed by any imposition.