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.
Discussion
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 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.
We need more drama here, so I appreciate that.
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.
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.
I think we should have a list of breaking changes. Changes to be merged should update that list if they change anything of substance.
wen NIP-1492... the discovery of 'murica