NIPs are no longer numbers #1621
Conversation
|
For backwards-compatibility we should specify that they are numbers for NIPs that are numbers and hex for NIPs that include letters. Yes, it's stupid, but I can't see another way. |
|
Or, you know, we could re-number the two new ones and forget this whole thing |
|
Allowing strings in a JSON array is not a very big deal. |
|
I agree, I just don't want to overcomplicate something so trivial. Edit I get it now, you want to make the array as string or int. Isn't that just waste of effort, compared to leaving it as just int[]? |
|
Why can't we keep using numbers? We should rename 7D and C7 back to an int and go over 100 nips. There is no need to add additional complexities when parsing NIP numbers. |
|
I think all we have to do is use decimal numbers instead of hex in NIP-11. |
You mean NIP-C7 would be listed as 199 in NIP-11? Please no 🙂 let's just keep ints |
|
We can't go over 2 characters in the NIP names, that would be a disaster much worse than allowing strings in the NIP-11 response. |
|
if letters are going to be allowed, please specify which characters, can we use emoji or hieroglyphs ?
i don't think there's any indication that this is hex, specifically |
|
I think the root of this problem is growing pains of the NIPs repo, not the numbering scheme. Maybe it's time to embrace NUDs: #1214 NUD identifiers would also be strings. So maybe we can take advantage of this opportunity to make NIPs and NUDs compatible. The only problem is we haven't decided on a scheme for NUD identifiers yet. |
I might be slow, but what would be so disastrous? |
To me, it seems that breaking the expectation that NIPs have numbers is a larger surprise than if at some point they'd need more than two digits. i doubt anyone expected the number of NIPs to be limited to 100 forever. And the usual way would be to allow for more digits (or do away with zero-padding completely, what's wrong with NIP-1 NIP-10 NIP-100 and so on-), not to extend the character set 😄 |
|
@staab Why did you use hex instead of int in the first place? Did you run out of ints, including the ones reserved for PR? |
|
If we allow for more characters we will have to rename all the current NIPs to prefix them with zeroes, breaking the git repository history and all the existing links to NIPs. Also there are many libraries that also expose modules named after the NIP numbers, so all those will also have to renamed and that will be a big breaking change in all of these libraries or at least a lot of unnecessary renaming work for developers. There are other minor issues, like having to keep track of a much larger address space for NIPs (1000 is much larger than 255, and I'm sure people will start picking numbers such as 999 as soon as we change the parameters). For a computer it doesn't make any difference, but we are humans (at least some of us), and I'm sure I am not the only person who has memorized some NIP numbers and have some rough idea of others based on their numbering and position in the 0-100 scale. Arguably allowing hex actually improves on this rather than making it worse because letters are related to sounds and thus are friendlier to human memory. Now if we support hex characters what do we break exactly? We allow strings in the list of NIPs on the NIP-11 response, which is a backwards-compatible change since JSON arrays are already not typed anyway. What else? NIP numbers are just arbitrary names, they're not essential to the working of the protocol at all, so if anyone was depending on NIP numbers as typed numbers rather than as names they were already wrong anyway. |
If we drop the prefixing, at most it would affect the naming of NIP-00..NIP-09. Could make an exception for them for URL stability and such.
As for "hex numbers are easier to remember", as someone who did programming on old computers i agree, i still remember many I/O addresses and even Z80 instructions-but i'm not sure this is a general thing 😄 |
|
It feels like we are just choosing the laziest solution. Why do we have to rename all the current NIPs to prefix them with zeroes? Just to keep files in the folder in decimal order? The file order also changes with the transformation to hex. So, I am not sure what this does besides just a cosmetic improvement. Renames on git don't break history. I am not sure where that is coming from. We can add symbolic links to redirect from the old names to the new ones. We can even change repos to keep links separate from the real files. We will have more than 255 NIPs. In fact, If we win, we will have more than 10,000 NIPs just to cover interoperable use cases. Anyway, I think the change to hex is just dumb and lazy. @fiatjaf if you want to keep NIPs to a low number, we need to split this repo and remove all NIPs whose sole goal is to propose an interoperable way to encode classes/objects into the tag array. We will have thousands of those. There is no question about that. Maybe that's the place for NUDs. NUDs can be where we map objects into tags. This means that a proposal has to either affect Nostr signatures or relay behavior to become an NIP. Everything else can leave this repo and grow infinitely in another space. In fact, If a NIP does both, affect relay behavior AND propose new object encoding, I would break it into an NIP and a NUD. |
Basically to provoke this discussion. I also drafted the first NUD. We'll need to add more NIPs one way or another. While I don't particularly care about keeping NIP numbers to two digits, I find myself persuaded by fiatjaf. The main thing is that NIPs have to be strings in order to accommodate NUDs, so whether we add new "official" NIPs via hex or decimal, supported_nips should always have been an array of strings. |
|
@alexgleason do you have anything in mind with regards to NUD naming schemes? I was thinking of something like Perhaps just an arbitrary name is better and enough. If you want to make a tweaked version of someone else's NUD (which should be a pretty rare event) you just give it a slightly different name. Otherwise if you are just trying to create confusion that is a good reason for your NUD to get ignored and we can't prevent it otherwise. Well, also NUDs have to announce in their own body how they should be referred in NIP-11 documents anyway, so they can introduce arbitrary characters in that in order to differentiate themselves even if they decide to use the exact same name as someone else's NUD. Another thing that we could address here is partial NIP implementation. I've seen people asking for this in the past and I've faced that issue myself at some point: how to announce that a relay supports a NIP only partially? The NIP could also specify conventions for that in its body. I can't really think about any practical examples of this now, though. After we figure this out we could introduce a new array on the NIP-11 response named |
|
We should also address specification updates. Meaning that specifications must be either versioned OR must NEVER change. If so, a new spec, with a new number/name, must be proposed to improve any existing spec. Let's not forget that NIP-11 is useless not because the spec was bad (which also is), but because NIP changes rug pulled relay developers into the mess that it is today. Considering how bad people are at naming things and the whole d-tag/title debate, I recommend keeping all specs ids to numbers. |
I created ANIPS for some of my proposoals that didn't get much traction here. |
Closes #1618