Oddbean new post about login | logout What are the breaking changes you're talking about? I'm not aware of any that you should be concerned with -- except for the NIP-46 proposed rewrite, about which I agree with you, but it was just a proposal.
Maybe it's less than I thought. It's just disconcerting to find any and not know how many I might be missing.
This one raised my hackles, then the NIP-46 rewrite PR got me angry.
d3dad11 ("NIP-46: replace npub1...#? notation with bunker://... (#1023)", 2024-02-06)
I'm going through the git history and I've probably overblown the problem. I think NIP-46 was a pathological case. The bunker:// thing was naturally adopted by all apps and no one bothered to write it in the NIP, it is also necessary for the relay to be included. There are other things still not written on the current NIP-46 that people are doing (Pablo's "oauth-like" flow) that must still be added there, which is a shame I think, I'm trying to understand how they work first before I add try to add them to the NIP myself.
In any case I would like to know if you have any other example because I've been paying attention to all these NIPs (even though I'm not personally interested in some so sometimes I may not look very carefully) and I've been trying to not allow breaking changes to be merged, so I want to know where I have failed.
You truly do stay humble. Thank you for jumpstarting all this 🙏
I appreciate that you've been trying to maintain backwards compatibility. Sometimes it seems like you're the only one. I had my head down for a week working on my relay (close to finished) and my github notifications were too many, so I tried to run through them as quick as I could and I think all these proposals that are breaking got to me. Yes, they were just proposals, but they are all over the place. People don't seem to get it. But you are right, it does seem that few of them get through. You're doing pretty good. I shouldn't have called nostr a "shit show". It was over the top. Got a lot of engagement though.
Case in point - nip46 nip04_decrypt method used to return [plaintext], which didn't make sense, but that was spec-ed. Snort implemented a sane, but broken version - expecting just plaintext string. It wasn't working with ndk that returned [plaintext], so I looked things up, people were proposing to "fix" it - change the spec, I saw 'No it will break implementations' comment and went on to fix Snort - make it accept [plaintext]. Turns out that was "fixed" in the spec now and changed in NDK - it returns plaintext string now, but Snort has no idea about it and now I have to unfix Snort. I'm not sure, maybe I and Kieran aren't following the right process to stay up to date w/ NIP changes but this kinda illustrates the point.
Weird, I was the one who made that change in a commit called "latest discoveries", so I apologize. But I don't remember why, it was likely triggered by learning that some implementations were returning just the plaintext string. I remember going through the Snort and NDK source code at this time trying to understand the unwritten spec, but that part got over my head probably and I just assumed it was a simple string since that would make the most sense.
Thanks for your work. How could I better follow NIP changes? Just watch the git repo on github? Maybe there could be nostr-nip-report account or hashtag that would scream at devs that there were some changes to existing specs? Some changes are inevitable so I'd rather stay up to date than stay ignorant.
I think we should have a list of breaking changes. Changes to be merged should update that list if they change anything of substance.
What if each nip is aware of how many clients use it, and nips can only be changed If the client's implementing it gave their explicit authorization?
How about a list of these changes in NIP repo readme, at the very top? Full dated list w/ full history (starting from today), so that whenever someone looks there they see it. The fact that it's at the very scarce readme space could help avoid normalizing changes...
I find cluttering the Readme not good. How about versions/releases of the spec. We tag a major version whenever there are breaking changes.
I don't like that at all. It adds more confusion.
The release history is normally where I follow changes of projects. To slap it onto the Readme ... an ever growing list of changes ... isn't how any project does it, so it's not really expected. If in one document, make a breakingChanges.md and link it in the Readme. The nice thing of a release history would be that one could easily find a summary not only of breaking changes but also new "features" and contributors could be mentioned etc. It would definitely something I would love to read as I can't follow all repo activity since a long time now.
I don't like putting it on the README either. I think such a document is likely to become outdated and useless regardless of where we put it.
That removes scarsity, and I have to remember to go to version history. Still better than nothing
Right now, the nip repo is just a collection of documents and people try to nip this and that and it's hard to know when something relevant happens. As a client dev you would not only want to know of breaking changes but also about new features relevant to your client. I certainly would love to have a chronological list of changes to catch up on but it shouldn't be a burden to those defining the standard so ... volunteers? Where is the @nipReporter?
Should be within nostr-protocol/nips so that changes to NIPs that are breaking can also add a line to the list. The README could have a link to it somewhere. Hell, I'll make a PR for this unless your definitely against
We can try that.