okay fine, my pronounce are "hubby/honey" 😑

Is this the oldest event?

Context: some clients are trying to push it to my relay and getting auth-required and then stopping, but I suspect they are trying to push every event to every relay or something nutty like that.

{"id":"41ce9bc50da77dda5542f020370ecc2b056d8f2be93c1cedf1bf57efcab095b0","pubkey":"5a462fa6044b4b8da318528a6987a45e3adf832bd1c64bd6910eacfecdf07541","created_at":1640305962,"kind":1,"tags":[],"content":"running branle","sig":"08e6303565e9282f32bed41eee4136f45418f366c0ec489ef4f90d13de1b3b9fb45e14c74f926441f8155236fb2f6fef5b48a5c52b19298a0585a2c06afe39ed"}

GM PV echo chamber 🤙

Plebs during this cycle

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.

WebRTC might be the biggest scam in all the "web" (aka Google Chrome) technologies.

I don't know about the ideas behind creation of WebRTC, but the way it was sold, and has been consistently sold for the last 10 years, is that it is a thing that you can plug in your code and it will magically work.

Oh, right, it also requires a STUN server, but look, you don't have to host anything, there are dozens of free public STUN servers on the internet -- and after that the WebRTC connection is established and you can freely transfer data, voice, video, everything!

Turns out WebRTC is useless without TURN servers, which just relay the entire bulk of the data and, most importantly, are not hosted for free by anyone for anyone else.

To this day developers keep dreaming of a magic peer-to-peer web that can be powered by WebRTC and wasting their weekends writing super nice projects that rely on WebRTC -- without TURN servers -- and therefore do not work at all. The worst part is that they always work when tested locally, generally in the same computer, two different browser tabs or even two different browsers (although in the second case no always).

I'm writing this because I just saw an anonymous developer talking about doing WebRTC signaling over Nostr as if that was the hard part. There is also a WebRTC signaling over Nostr NIP proposal. These things are everywhere. I have myself written at least two projects that relied on WebRTC in the past hoping that time it would be different and p2p would work.

Ship code, read philosophy. It's simple really.

I always hear these things "we are early", "things are improving" and so on, but to me everything is the same buggy as it has ever been, sometimes worse because more adoption means more bugs. This is not only about Nostr. I see so many bugs everywhere.

What has actually improved in Nostr in the past 10 months?

Now we have a chain of dependencies in the NIPs. Soon we will need npm, the NIP Possibilities Manager CLI tool and a nip.json file.

Gm nostriches.