Oddbean

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.

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.