-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Store the nsec as ncryptsec #55
Comments
Yes, will implement eventually. Thank you for the issue. |
Thanks for implementing the above... but seems to be incomplete. A "complete" (functional as intended) implementation of NIP-49 would allow one to "import" an ncryptnsec as well as "copy" it out to the clipboard. To you have plans for this? Thanks. |
@manimejia I think these two requirements are implemented, no? However the secret key is stored in plaintext, not encrypted. I am not sure how to properly implement it so it is stored encrypted, but maybe I'll do that eventually. |
Thanks @fiatjaf . As far as I can tell... current implementation only allows to encrypt a private key (for copying OUT) but not to decrypt. I'm suggesting to allow PASTING an encrypted key (ncryptnsec) into a text field (along with a password) for decryption and storage by the key manager. Even if you store it in plaintext, copying and pasting (or QR scanning) encrypted keys between clients is WAY better than unencrypted. Worry about encrypted storage later. But that would be cool also. Thanks. |
No, you can paste it encrypted. I'm pretty sure. I can't test now because I can't delete my key from the extension, but I know I wrote this code in the latest release. Maybe it is broken. I'll check later. |
I'm requesting to include the encrypted nsec (ncryptsec) and request the password in the client to open the extension. I'm requesting this because it bothers me that my nsec is available for copying and viewing just by pressing the button "show key".
I understand that it would be less problematic to temporarily store a password capable of opening the encrypted content than to directly store the nsec permanently.
This make sense?
The text was updated successfully, but these errors were encountered: