Conversation

Notices

1. Embed this notice
   mikedilger (ee11a5dff40c19a555f41fe42b48f00e618c91225622ae37b6c2bb67b76c4e49@mostr.pub)'s status on Saturday, 17-Feb-2024 05:48:28 JST mikedilger
   Nostr is a giant shit show. The fact that our software interoperates at all is a miracle and probably just a temporary anomaly. Given enough time, the relentless breaking changes being made to published NIPs will eventually break everything.
   
   Linux succeeded because "WE DO NOT BREAK USERSPACE". For nostr to succeed, changes must "NOT BREAK EXISTING IMPLEMENTATIONS". There shouldn't be any exceptions to that EVEN IF THE IMPLEMENTATION WAS NON-COMPLIANT.
   
   Pay close attention to Linus right here:
   
   > Are you saying that pulseaudio is entering on some weird loop if the
   > returned value is not -EINVAL? That seems a bug at pulseaudio.
   
   Mauro, SHUT THE FUCK UP!
   
   It's a bug alright - in the kernel. How long have you been a
   maintainer? And you *still* haven't learnt the first rule of kernel
   maintenance?
   
   If a change results in user programs breaking, it's a bug in the
   kernel. We never EVER blame the user programs. How hard can this be to
   understand?
   
   Linus doesn't want to break pulseaudio EVEN THOUGH pulseaudio was doing the wrong thing.
   
   It seems like every week I find a NIP that I've coded for has changed. This last week I think it happened three times already. Sometimes it's a small change and I quickly update my code. But I can't read all the PRs, and I'm afraid dozens of small changes have slipped past my notice. Gossip is probably now incompatible with multiple other implementations which happen to have implemented different versions of the same NIPs (some older, some newer).
   
   Even if we didn't have any breaking changes, the simple fact that different software implements different optional NIPs itself presents to end users like broken software. Why does it work in Damus but not Amethyst? Why does it work in Amethyst but not Coracle? That is an even harder problem to solve.
   
   But let's at least solve the easier problem and stop changing NIPs. If you don't like a NIP make a new one, don't break the current one. Even if you think the current one sucks balls and should have never happened. Even if you think there aren't many implementations out there.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Saturday, 17-Feb-2024 05:48:28 JST Alex Gleason

     in reply to
     @ee11a5dff40c19a555f41fe42b48f00e618c91225622ae37b6c2bb67b76c4e49 It's actually okay if interoperability is broken at this stage. We are not even close to critical mass. Compatibility issues are not going to kill us at this stage because we frankly don't have a lot to lose yet. I think actually the opposite is true - if we refuse to offer a better experience because we are too afraid to break things, that will be a greater detriment to us in the long term. It depends on what it is, and good judgement is needed. But it is a balance, not an absolute.
     
     Also, Linus is a visionary leading a centralized project. It's different.