Sure, let’s just be pasting our private keys everywhere then 🤷‍♂️

Reply to this note

Please Login to reply.

Discussion

signer extension?

Web extensions are not safe

Why not? Open source, Chrome sandbox... probably better than random websites.

what’s not safe about nos2x

Web extensions are vulnerable, have privacy loopholes and frequent hacks. Would you save your bitcoin private 🔑 on a browser?

They aren’t audited well.

The best way as of right now to generate your 🔑 on offline device(for example seedsigner) and then allow client to sign events. Hope there will be more ideas how to properly manage 🔑 but definitely not a web extensions

both web extensions and websites can have security vulnerabilities. both web extensions and websites can be safe or unsafe depending on their design and implementation. which client are you allowing to sign events?

Using web extensions for storing private key is bad. Point! There should be better alternatives to it! One of the alternatives been already proposed 🤷‍♂️

What do we need to support to get this on iOS? Use their secure element thingy? Or is that a bad idea?

Add a passphrase to a private key

Is the fact that the current state of things imperfect a justification for doing anything?

Nothing is perfect but gotta start thinking about safer alternative implementations 🤷‍♂️

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.

Well, I guess then it’s time to make a new NIP proposal if you have something better on your mind🤷‍♂️😉

You are funny.

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.

So if you are not convinced then no chance anything will be merged right?

If you really want it I can merge it as an experiment.

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…

https://github.com/swbratcher/nips/blob/master/NSUB.md

Can this be chewed up and spit out? I’d love to see your take:

https://github.com/swbratcher/nips/blob/master/NSUB.md