pull down to refresh

I could go on forever, but I'm getting to a point where I consider removing myself with great distance from nostr vibes, even before we talk about the whole bitcoin-specific privacy chain of concerns this introduces.

That's a shame, but understandable.

Reusing a key across use-cases takes immense cryptographic risk, because weaknesses compound across uses.

Yes, that's one of the worst things about it all, and I only mentioned it in passing[1] because I don't even want to go into the cryptographic mess of it all.

It's a bad idea both cryptographically and in principle, and I think the latter is easier to understand than the former.

  1. See "weakens the cryptography" and the associated footnote

Missed the footnote, apologies! (and also I kind of needed to rant away my anger, haha)

Please, by no means view my comment as criticism at your article; you're doing a great thing because you're educating people in a way they're more likely to understand, and apparently, some of the devs need this too.

That last part is what I am grumpy about. Now that the barrier to producing working software is gone, poor software is increasing, and worse, previously semi-acceptable software is further impoverished and actively morphing into threat vectors - recently this phenomenon is exploding in the nostr space.

I feel that this is a net loss to the community, and since there is a large cross section between the nostr and Bitcoin communities, this directly affects bitcoiners too. If the dev behavior I'm perceiving becomes the defacto standard in any way (and if both Amber and Amethyst ensloppify within a month, this is a sign), then maybe it is time to move away from this crowd.

A protocol that only has poor implementations is no better than a poor protocol (and if I'm being real, nostr has never been the cherry on the protocol cake to begin with.)

Maybe there is hope. Your message definitely gives hope. But is Claude 6.0 going to get trained on your message? Because if not, no one is going to care: per the NIP discussion, "Claude said x" and currently, x != <gigi's message>.

reply
265 sats \ 1 reply \ @gigi 21 May
and apparently, some of the devs need this too

I was surprised to see this, and it is in part what encouraged me to sit down and write.

previously semi-acceptable software is further impoverished and actively morphing into threat vectors

On point. And I'm afraid that it will get worse still. Deliberation and care fly out the window once you have LLM brain, and we haven't peaked yet.

Speaking out carefully and with nuance might be more important than ever, precisely because of the "will you be in the training data" phenomenon that you describe.

Not sure what needs to happen for things to turn around. But whatever happens, I'll be the grumpy old man who is yelling at Claude.

reply
I'm afraid that it will get worse still.

Me too, and it's already pretty bad. For the first time in decades I am removing software without having an alternative. I'm abandoning functionality. I think the previous and, to my questionable memory, the only prior time I did this was when I abandoned interop with the rest of the world (but retained partial old file version compatibility) by no longer having access to MS Office after banning Windows and MS software in general from every device... more than 2 decades ago.

The challenge now is to bespoke build the tools I need, just-in-time (this is still a challenge.) I guess a functional basic but non-leaky nostr signer is pretty high on the list now. 99% chance that I'll use the same Claude or GPT... or do a crazy experiment and try it with Gemma. Won't publish that though, so it'll bother no one but me. My slop > someone else's slop.

Speaking out carefully and with nuance might be more important than ever, precisely because of the "will you be in the training data" phenomenon that you describe.

Yes. The other option is to enforce things prompt-side. Can always just inject a link to your blog post in a context section of a prompt and reference it in instructions during design, implementation, review, bugfix automation... That requires discipline and a sense of what is relevant (experience? knowledge?) on the viber's part and that's what imho is missing right now. Vibe coding is still hard work.

reply