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.

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

Reply to this note

Please Login to reply.

Discussion

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...

I have been scratching my head about the WebSockets too. But here we are. And it seems to work fine.

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.

I have yet to read the protocol(s) in-depth, but what would stop a relay from offering an alternative transport and falling back on WebSockets?

there is nothing stopping it, it's really easy to implement, at least in #golang i could have a gRPC/protobuf version of the protocol working in a matter of a week or two

the only minor hassle is that checking signatures on events requires converting them into a special format of json array, to get the id hash, but for lazy checking you can just enforce a uniqueness invariant on the ID (bake it into the key value store) and just check the signature matches the ID and pubkey, a single time on receiving an event you might have to actually construct the canonical form and validate the hash matches the ID, technically that's it - match the hash, hash to the signature, validated, it's a shortcut but it's secure

i would love to do this task btw, i would make actual distinctive sentinels for the two types of count and auth envelopes, so they don't have to be scanned ahead as they do in json

At first I thought gRPC/protobuf is not a transport protocol. Then I see that WebSockets has data framing and messaging. Is gRPC/protobuf light weight, though? What about Cap'n Proto? Or what about plain old UDP? I already see the bulk of relays have <50% connection success, so we're not expecting reliable transport are we? I guess UDP would mean reinventing some stuff. Again, I am speculating as an aloof user.

grpc is lightweight, pretty fast, more universally supported than capn proto for other languages including javascript! and and gRPC's default transport is QUIC which is a UDP based replacement for TCP which aims at fixing "head of line" contention

if there is any candidate for an augmentation to nostr protocol it's gotta be grpc/protobuf

protobuf is the encoding, grpc is the protocol, it handles the request/response flow

If the use for a second protocol is non-browser non-JavaScript non-JSON then there is no need to support JavaScript. If the goal is to fully replace WebSockets/JSON, then yes, it would need to be something with wide support such as gRPC.