nips
nips copied to clipboard
nostr-protocol
Decentralizing the NIPs registry
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.
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.
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: NIP 2023-Ostrich
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?
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:
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 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 changeThe 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?
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 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
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.
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.
kind 11 with
dtag pointing to article title -> article body that can changeThe 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.
So I think at this early stage there's a need to prevent collisions:
I very quickly made this:
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.
@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)
Work in progress, a little html page that will display NIP numbers from JSON
https://nostrdata.github.io/kinds/
Two very good resources here:
- https://nips.be/search
- https://nips.be/nips-info.json
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:
- 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.
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.
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.
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?
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.
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.
