Well, my point was that no one thought about this question a single minute. Everybody just read NIP-26 and assumed it was the solution. NIP-26 is not a solution for this, it was made for temporarily delegating to third-party services because of the https://minds.com/ integration. And it was meant to be the least disruptive possible.
I can think of multiple other methods for doing delegation/revocation that would be better if the goal is to protect keys.
the thing is that even for that use case, which is exactly the use case I had in mind when I started looking at it (https://nostrit.com could be done much more elegantly if NIP-26 was better).
I think having a proper key delegation where user of both keys are the same person definitely needs to be solved,
but NIP-26, or something like it, where you can give *some* permissions to a 3rd party without giving out the full reigns to the kingdom, would be valuable.
I agree, but not all desirable things are practical. I am not convinced that NIP-26 is worth the cost, but if proven otherwise that will be good news. Maybe we need Nostr 2.0 that fixes all the bugs with Nostr 1.0.
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 and nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft I started putting together a NIP that would address needs that are arising and found that elements overlapped with NIP-26, so I shifted for a graceful interlace of features. But the more I look at NIP-26 it is becoming evident that adoption didn’t catch on, too many unresolved issues linger, and there may be some divisive baggage associated in its old age.
Would I be better off not trying to work with NIP26 and just going with an all new NIP even though it overlaps some with the problems NIP26 is trying to address? And most importantly, since I’m new to the room, would either of your be willing to read my ideas in a NIP draft form before I submit anything?
NIP-26 is a failed promise that can't be resolved -- don't look there for answers, it has none.
So yes,. overlap on use cases it's good, but its solutions are bad (specially because they look initially look sound).
And yes, just publish your thoughts here you'll get more feedback than you wanted to receive 😂
I often write a NIP in very draft form (mostly just the data model and one or two paragraphs explaining what's not readily apparent on wikifreedia.xyz and then publish it here.
Thank you for the detail. It offers some perspective. I’ll unmerge the NIP26 accommodations that I incorporated and let it stand on its own as conceived. Once it’s ready, I’ll look for feedback and scrutiny.
Here’s the current draft of the idea in GitHub, where this discussion may belong…
