-
Notifications
You must be signed in to change notification settings - Fork 543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decentralizing the NIPs registry #162
Comments
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. |
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. |
Yes to this. Make NIPs great again |
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. |
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: |
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? |
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. |
Could we use parameterized replaceable events? We just need a client that supports editing and then the conversation can happen on Nostr. |
I was thinking of doing editable texts using parameterized replaceable events, like this:
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?. People could comment on the article and suggest improvements w/ patches as git diffs? |
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? |
We could always store the old content inside of a Either that or there could be a new kind of replaceable events that has a history feature. |
Yup. Makes sense.
You are right, replaceable events are not good for this, the history (commits) is important. I think We could have forks so perhaps It almost feels like we'd be recreating |
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. |
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. |
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. |
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. |
This comment was marked as spam.
This comment was marked as spam.
@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) |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
I like the idea that people can vote for nips just by clicking the like button! |
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? |
I wrote an article on this topic here. The key take-aways would be:
|
Proposing #400 to overcome event deletion. Proposed NIP also contains how a nip registry could work. Edit: Concerns expressed above are
|
It would be interesting to write NIPS here: fostr.dev |
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? |
Yeah, I think most people probably are? @Giszmo is the only one publicly visible on the org |
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 |
Ok, so I've looked and I don't know how to set my visibility as public. |
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. |
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. |
I don't either, I didn't even know it was private |
Yeah, it's very hidden, I also had to look to reveal myself: |
current users who still have it as private: @alexgleason @atdixon @BrightonBTC @cameri @eskema @jb55 @mmalmi @ottman @Semisol @verbiricha |
Maybe a |
Contributors with npubs, not with GitHub users. |
I think a CONTRIBUTORS file solves nothing, and having merge powers isn't the same thing as "contributing". |
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. |
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: 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. |
@alexgleason I told Melvin this and he ignored me. I do think it's a bad idea to couple everything to github though. |
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. |
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? |
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. |
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. |
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. |
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:
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. |
@weex thank you for the summary. It's a non-problem that becomes a problem only IF you attempt to solve it - my cent: |
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 sometimes use https://nostrapp.link to look up event kind, and see what apps use them. Not sure how the decentralized wiki could work... |
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 |
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. |
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 |
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. |
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.
The text was updated successfully, but these errors were encountered: