NIP-60 cashu wallets should have used replaceable event kinds instead of trying to rely on kind 5 delete events. It causes the app to have to sign two events just to update a "token store" event and my app still needs to download the extra kind 5 event because relays do not actually delete the old token event. #replaceableeventsforeverythingexceptkind1

Replies (9)

Not to single NIP-60 people out but I witness almost daily terrible architecture decisions in all kinds of software from FOSS to startup to established Fortune 500 LLMs made implementing code faster and cheaper but it can't fix stupid architecture choices. Seriously think about all the shit that can go wrong before you lock in a design choice folks.
I’ve also thought kind 5 deletion events were the Achilles Heel Replaceable events make more sense
They are great for users deleting events they want to retract or remove, but I don't think they should be used or replied on in NIPs. too much complexity
Yea. And I would consider that amateurish. Especially considering the fact that you can absolutely prompt them to look at it from different angles. Imo devs should spend 80% of their time looking at block diagrams and call stacks and thinking about what can go wrong. How they can design fallbacks, proactively design against failures, optimize speed etc. The implementing of the actual loops and helper functions is not nearly as important as understanding how pieces fit together and ensuring that they perform as expected both individually and when combined.
Interesting. Did you build a proof of concept wallet with this? Sounds reasonable.
A lot of parts of nostr are like that. Frustrating. Devs need to agree on a more intensive review policy for nips. Especially before it gets added to the quote-unquote official list.
The problem with NIPs in general is that people fall in love with their own idea and it ends up being their own personal NIP. They don't consult anyone outside their bubble and and they're in a rush to get it out. The good NIPs are huge far crys from that. But they're the exception. I've had a dev try to nerd snipe me solely on a "clout" basis with no real concrete reasons why my approach was "bad". Years later here we are - his NIP still sucks it's inefficient and he has to cave and implement half my suggestions anyway. Less ego, less bickering, more collaboration and more proactivity.