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.

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.

Reply to this note

Please Login to reply.

Discussion

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.

If only #Nostr hadn't gone with #JSON

With JSON, with WebSockets, with Bitcoin fanboyism, with specs on GitHub, with a lot of other things that actually hurt more than help.

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.

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've already been through the protocol grieving stage. 😂

I can, but I won't. Or as you say my work will just be at the most basic level, which is unfortunate.

It is, what it is.

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.