What was wrong with nip-26 and how was it flawed on technical and security levels?
https://github.com/nostr-protocol/nips/blob/master/26.md
🐶🐾🤔🤔🤔🤔🤔🤔🤔🤔
Discussion
I'd be curious to know as well because I thought delegation keys were pretty fucking mind-blowing when I figured out what they did.
Exactly! And I haven’t seen any evidence of it being broken in any way 🐶🐾🫡
As someone that tried hard to make use of nip-26 - the problems were lack of support in clients + it only covered the base use case, was meant to be more fleshed out in time, but it never happened.
I see. But, if we were to develop that nip further, it could be so useful and also it could indicate who sent what on who’s behalf (scheduled notes, etc) 🐶🐾🤔
"delegations" are called "certificates" in TLS/X.509 why invent new terminology
Never paid attention to terminology, TBH 🐶🐾🤷♂️
It doubled the complexity of storing and working with events. Also made indexing and finding all events for a pubkey a little more difficult.
I agree its a really cool idea. But for a client to support NIP-26 it would have to support the possibility of two pubkeys for every event it sees
It sounds easy on the surface but it double the complexity if everything downstream of events (which is the whole client)
Ok, that makes sense. I wonder if it’s worth the trouble. To me it seems it’s worth it, but I cannot say how much of a trouble it is 🐶🐾🫂