It's annoying to copy your nsec from your phone to the browser's extension on a computer.
What would you prefer?
1. get the desktop to turn on the camera to scan an app-generated QR code with the nsec?
2. find a way to represent the nsec as a list of words so that people can easily write them from one device to another.
Any other ideas?
Parent-child key generation, and management with shareable key. I do not want to copy the same nsec everywhere.
The first one was complicated.
The second one is probably the good one.
QR may be the simplest but I worry it will encourage people to take a screenshot. On iOS I can copy and paste using iCloud.
What if Amethyst let you extract the key but protected by a passphrase you had to enter on the desktop client?
Would this require a new NIP?
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft Is this one of your 46 ideas?
Nope. My idea is making remote signing as easy and self-sovereign as possible which makes this kind of problem obsolete.
Remote signing works. But remote decryption doesn't. There are too many things to decrypt in a single screen. Making a decrypt call for each message in a DM chat screen takes a long time.
We have been discussing this on https://github.com/nostr-protocol/nips/pull/746. Where the idea is to not have a decryption call on NIP-46 but a shared-key assembly call. Client can call it once and with a single key decrypt/encrypt all messages locally.
⚡️
I think that the default storage should be desktop, and we should find better ways to communicate the nsec to the phone
Password managers are the default, and they operate between desktop and mobile clients. No need to pass anything between different devices manually. Autofill within browsers handles also the transit from the manager to browser’s field without clipboard.
Passkey or true delegation would be the ideal.
But 🤷♂️ if the nsec delegation is not feasible.
Bluesky has those limited passwords and they are nice. Revokable tokens on Mastodon instances with oAuth2 are convenient, too.
Nostr should use normal methods if it wants to become mainstream.
On Apple ecosystem, this works locally and without lockups from vendors: https://strongboxsafe.com/
Very few people even know what password managers are. If you have to onboard them into a password manager before you can onboard them into Nostr, you already lost them.
Apple has the native keychain so that’s the default option and it’s well integrated.
But to answer your question: 1)
My bank uses QR code on browser that seems to be dynamic (moving pattern) and you point your mobile’s authentication app with camera to it and it let’s you in.
export a file (key?) and then import the file is a method I am quite comfortable with, as an example...
I prefer key delegation. Signing a delegate nsec via QR code.
Either way you would have to manually copy then the pubkey then from one place into another to set up the delegation.
But most clients will never implement delegations, so this is a non-started to me :(
I really like QR codes, I would just never put a private key in one as it makes them too easy to steal.
If I maintained a client I'd keep it open as a possibility because delegation removes the need to copy private keys between devices. No longer need to copy keys in any form, could be made to work with a hardware device, and the cryptography is simple, so why not try it?
1
I like the idea of a list of words. Simple.
No. 1
I don't get it, why want so much people to put a bunch of words somewhere, when they could easily could scan a qr code?
Sub nsecs that can be generated from amd revoked from the secret, like bitcoin addresses and gpg keys
You can derive the primary secret from those, right? Is that your intention?
Re-reading the post, i think my solution is for a different problem, using nsecs accross devices and platforms, not ease of use.
I think that's what he wanted. Conveniently migrate to some other system/platform. Make the nsec available there. What I understood from you was: why not derive a key to use there. Which could work equally well. Only, I then realized that this key would endanger the original nsec. So I may (also) be thinking of the wrong goal. 😅😂
The sub key would not, because it is derived accross one way cryptography. Like the way sub addresses or GPG keys can be derived from a single secret but not hint at the seed itself. (Otherwise we would all be screwed) Think of it like having two identical cups made of glass. You break one, throw away the larger pieces and use the dust from that as an address that matches with the one you keep hidden. There is no easy way to recreate the glass based on the dust, but the dust finds a matching place in the unbroken cup.
What i realized is that if we could do that with nsecs, it would still be a huge clumsy number that's not easy to send to a desktop application. As the OP suggested, something like a QR code is easier.
Mnemonics is the easy and known way. Also we can store oN HWW.
list of words
Use an app like 'Wormhole'
Tattoos.
Just kidding.
List of words would be awesome.
The browser extension should request authorisation with an ephemeral key, to which the phone app can respond with an encrypted ephemeral message after confirmation by the user.
So you want your private key inside a Nostr message out there?
There are no emphemeral events in the web. Somebody is always saving something. People are always watching.
Doesn't have to be over the greater Nostr network. Ideally over a relay you control, so you can ensure its not leaked.
But QR code is fine as well. 😎
2
