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 🐶🐾🤔🤔🤔🤔🤔🤔🤔🤔
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 want to add it to nostrdb+damus and strfry. Its still doable
Let’s go! I think it’s good and opens some use cases that are not possible. Also has clear distinction that event is not by the original poster 🐶🐾🫡🫂🔥
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 🐶🐾🫂
Personality I would go with NIP-46 over NIP-26
They serve different purposes AFAIK, and more centralized. Unless my understanding is completely off 🐶🐾🫡