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.

[staab]

Maybe a CONTRIBUTORS file would be a better way to do this. https://github.com/nostr-protocol/nips/pull/883#issuecomment-1816737715

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