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.
Login to reply
Replies (3)
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.