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.
Replies (56)
100% new NIPs should break old NIPs but can improve or add a feature. kind of same analogy BIP forking bitcoin or rolling out segwit n taproot while legacy address still can work
PulseAudio was a sh-tshow for YEARS, Linus should've taken a harder line.
That said, generally I agree with your point, and I greatly value stability and performance over feature-creep, but I'm not the user talking to the devs unless they've broken something.
The user listened to is the one that wants a floating birthday cake overlay on her birthday, and she doesn't care what the devs have to break in order to give it to her!
Is the answer to different implementations of the same NIP to have a Plural Layer of Execution?
View quoted note →shouldNOT
shouldn't
Just being real, I wouldn't keep developing in this sort of environment. I'd just bounce. I've considered developing on Nostr but this concerns me. I simply won't do it.
Wabi sabi repairs … awe did I understand something from my spiritual to programming? Constantly mending & making better (hopefully) as we each build on the next level …
It's called backward compatibility.
The problem with that is that protocols have a network effect. I can't walk away and write my own protocol, nobody will use it. We have to work together, as hard as it is sometimes.
And that is why I spent a week writing a custom JSON parser, even though the whole time I was thinking "if nostr was a binary protocol I wouldn't have to do this shit." But I have to do this shit, I know I have to do this shit, and I do it anyways.
Then I see other people without a care in the world pissing on this and pissing on that, and it enrages me. Sorry, I'm human.
Breaking other people's work willy nilly isn't working together, and that's the point here.
I'm speaking up about it. That might solve the problem. We will see.
You can do it, but you have to sort of stick to the lowest, most-basic concepts. As soon as something gets more topic-specific or detailed, expect it to change rapidly and/or go off on some tangent.
The problem seems to be that active product developers own the repo, so they use it like a place to dump their product docs (so they change with every change to their implementation), instead of as a place to specifiy overarching concepts that everyone can agree on.
We've learned to basically ignore the repo. 🤷♀️
I don't know if they're even aware of any devs outside of their little ingroup, anyway.
I was feeling the same. Things changing would be fine, if there was some way of knowing when something has changed, or if we knew the breaking changes, if any, would only get merged once every n months, on a particular date.
I've already been through the protocol grieving stage. 😂
You forgot rule #0. Nostr is not a firstmover. Even if code is / will be perfect it still loses against the firstmover X. #bitcoin is the perfect example. There is no second best. And that's a good thing for us bitcoin erst.
"never ever blame the user"
View quoted note →If only #Nostr hadn't gone with #JSON
Apples and oranges comparison.
you have bad taste in programming languages but this is a fundamental also to bitcoin as well, indeed lightning hasn't broken old stuff very often either
in many codebases you will find things with the term "quirks" and even in bitcoin there is quirks in its handling of JSONRPC2 that have to be accounted for in case you are interfacing with an old version that does different stuff
the escaping of strings is a good example
Even if we had a list of breaking changes and I could remember that I was compliant up to change #23 then I could see how many new breaking changes I need to keep up with. Not great, but better than what we have now.
Ideally though we have very few breaking changes. I understand sometimes the alternative is horrible and the breaking change is needed to 'save nostr'. I'm okay with it if they are few and far between, and well communicated.
But when people just think "Eh, this NIP could be done better. Let's do it my way. I'm gonna rewrite it" that is where I think things have gone off the deep end. The new ideas are great ones, but they are different, therefore IMHO it needs to be a new NIP, not a change to an existing NIP. Those kinds of changes shouldn't get merged.
I can, but I won't. Or as you say my work will just be at the most basic level, which is unfortunate.
But Nostr is also very young. I think it's perhaps been adopted much faster than it should have. That is, in my opinion, how tech will be moving forward. 2-3 years is the new 10 years. It is important that developers start getting serious about Dev standard operating procedure in general if we ever want to see real freedom in our lifetimes. The stakes are higher than games now. End philosophy rant.
It is, what it is.
Bad taste in programming languages is something that led Nostr to use WebSockets instead of normal TCP sockets in the first place, introducing huge bloatware layers on all sides.
But again, this choice also come from someone who believes there are no other version control systems than Git and no other Git hostings than GitHub...
thanks for raising this subject to increase awareness
Thank you for your work 🫡
With JSON, with WebSockets, with Bitcoin fanboyism, with specs on GitHub, with a lot of other things that actually hurt more than help.
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.
@TheBitcoinManual this is what I was referring to ;)
Sebastix (npub1qe…ezefe) on Nostr
Short Text Note by Sebastix
I think I've broke Nostr in someway in my case: both Coracle (desktop) and Nostur (iOS) have stopped loading my feed. Damus (iOS) and noStrudel (de...
Coracle and Nostur both haved stopped working with my account.
When I use another account, everything works fine. So I make the assumption there is some related data to my account which is breaking things in those clients...it's not fun when you suddenly you can't use two of your favorite Nostr clients anymore. 😢 For now...
I don't know, but maybe there is a bug in a library they both use.
You mean a NIP (which is a specification in my understanding) changes over time? Is there no change management like versioning of NIPs?
Even if the analogy isn't spot-on, we're battling one of the biggest advantages Bitcoin and X have: the network effect.
@Lyn Alden has some cool thoughts on it here:
https://www.lynalden.com/bitcoins-network-effect. If we can come up with a game-changing use case (think Bitcoin payments), we might just have a shot at beating the beast.
Clones or undistruptive improvements will never do it
I do not agree. Teh current main use of Nostr (twitter like) is not a first mover (and I would discuss about this as well. Nostr as a protocol is indeed a first mover.
Is this why my #amethyst stopped working for no good reason?
Hope you are right 👊
nostr is to x as bitcoin is to monopoly money
It seems to work fine... on mainstream browser engines and hipster shitcoding platforms like NodeJS. Everyone who wants to live more frugally is left out.
"HEY GUYS! LET'S MAKE NOSTR LIKE SYSTEMD AND PID1 ALL THE THINGS!"
No one can keep up with the 8`742`000 lines of code in the protocol BUT IT DOES THINGS!
Hardware normally degrades with age
Software normally improves with age.
Chill
How about a mailing list lol?
What's wrong with replaceable NIPs?
View quoted note →farcaster is crap. The closed source client warpcast is garbage. All the alternatives are also closed source. If you try and have a conversion with more than 3 replies it gets filtered out. You have to constantly tap 'Show More' as more content is filtered out. It looks good on the surface until you try and use it.
I get what you're saying
But as a long-time web developer I have to point to web browsers
I was grumpy before you. j/s
#nostr
it isnt a hardfork until they break kind 0 and 1
#nostr
NIPs should be discussed, then made static or at least developers should agree to implement the first version of it and then keep it that way.
View quoted note →Actually I am not aware of these breaking changes. And I develop a client too… what are you referring to?
Can't blame them for being fans of the best money ever created. Also, it's still really young. People forget that
"Best money ever created"? This is an perfect example of the fanboyism I was talking about. And no, being a fan is not the same a being a fanboy.
Your "best money ever created" is traceable, slow, expensive, energy hungry, poorly scalable and non-quantum-resistant. Almost every blockchain created afterwards mitigates at least _some_ of these issues, while Bitcoin couldn't deal with any of them even after multiple hardforks and format changes. LN is a workaround, not a solution, and it doesn't address all of these issues either, just adding another layer of complexity on top. Besides, 2+ competing and incompatible LN implementations don't help mass adoption either.
Why first create problems on your own and then heroically overcome them? No blockchain is ideal (IOTA was close to that but they dropped WOTS in favor of ECC), but almost every choice is better than Bitcoin in this or that aspect. I'd go with Monero if we're talking privacy-oriented environment here.
But the broader question is: why even tie Nostr to the quirks of a specific blockchain, unless, of course, the notes are distributed directly on that blockchain? That would eliminate the need in separate relays either: blockchain nodes would be the relays.
Blah blah. Don't use it if you don't agree. I don't really give a shit and I doubt anyone else on Nostr does either.
I also get that feeling. should I really be able to be naughty and someone's issue on a project I don't maintain? I have considered restricting it to just 1) user who raised the issue and 2) repo maintainers (OPTION 1).
then I thought that complexity shouldn't be added to the protocol to solve potential problems that haven't manifested. this has to be traded-off against the adding to the protocol when other have started to implement it. This thread illustrates how this annoys developers and leads to partially implemented NIPs:
View quoted note →
So what is the problem with being able to change a status on an issue or proposal I didn't create on a repository I don't maintain? I think it is:
1) malicious actors who change statuses to create chaos (SPAM status events) - couldn't this be dealt with like other SPAM?
2) users who, operating in good faith, close or reopen an issue / proposal but don't understand the maintainers approach, or wider context around why this sort of issue / proposal should remain closed. perhaps there could be the option to add a 'locked' hashtag which means future status events from non-maintainers should be ignored (OPTION 2)?
