Good question, I was wondering the same

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 we should have a list of breaking changes. Changes to be merged should update that list if they change anything of substance.

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.

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?

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.

In GitHub you can do something similar by setting file "code owners" under "branch protections Policy"

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.

Yes, I want to see this too. A list so I can catch up from where I left off. Anything that might be a breaking change should be on the list.

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

Well anywhere we put it can become outdated if not maintained

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.

wen NIP-1492... the discovery of 'murica