Oh wow, amazing! I didn't mean to discourage the bunker-link approach - nip05 doesn't remove the bunker-links, maybe when there is an OAuth-like flow we'd get rid of it. The nip05 would just be useful for logging into the Signer on a new device - it's easier to remember than npub.

Pop ups look awesome, nothing to add atm! 

I would think on the Your Key section on homepage more:
1. The bunker link is not a 'key' - it's not secret, and we probably shouldn't mix the terminology with private keys. 
2. I don't think we need to show the bunker-link on homescreen - it's content is meaningless and only useful rarely to connect a new app.
3. How about a 'Connect app' button that shows a modal with a QR-code of bunker-link, 'Copy' button, and a 'Paste this code to your app' message?  
4. Also maybe a 'Cloud sync' button with a checkbox - shows a modal that explains it and asks to enter the password, checkbox turns checked after it was all set up?
5. Maybe we should show the npub under Your key section (instead of bunker-link) - as much as I think it's an awkward thing for normies, we won't get rid of npubs any time soon, and many apps ask for it, so a quick way to see and copy it would be useful. 'What is this' would show a small explainer about npub.

WDYT?

Re. the name - we have nsec.app domain name for it, let's call it 'Nsec app' ? I store my nsec/keys in the nsec app :)

I like the style, could we also have the light theme?

Re. drawing the nip05 stuff - without it user would have to remember their npub and password to login into the Nsec app on another device. The nip05 would simplify it to email-like nip05 and password - much easier to understand and remember. So maybe nip05 could just be displayed under the user's name near the avatar - would help people remember it? And of course on the Nsec app login screen, and maybe on 'import key' screen.

Thank you for your help! #nostrdesign 

 Great input sir, makes it a lot better. On it! 

1. Just called it "Key" because that's what Snort etc ask for in the field where you paste it. But you're completely right. 
4. I drew the "cloud sync" option first but it didn't work in my design, in your idea it does, me gusta. 

Btw: I think indeed the way @PABLOF7z sees it, you can skip the bunker-link entirely and just use NIP-05 + password in general.  

 Thank you!

Agree, the flow that Pablo is working on would eliminate copy pasting the link 

 From the picture it does seem like nosskey! 

 This seems to be nossky where the password-encrypted key is given to the server.
But the mechanism for signing using the nsecbanker mechanism is very smart.

I'm going to look at it some more..😁 

 @brugeman
I was wondering about one point🤔
Is the password the only thing needed to get the encryption key🔑 from the cloud server? 

 Yes, right now it's only password. I was planning to add webauthn later as second factor. 

 That's great. 
As a matter of fact, nosskey has it
I've implemented it as a prototype.
You may be able to use it as a reference.

https://github.com/ocknamo/nosskey 

 @brugeman
You mention using webauthn as a second factor.
But in my opinion, only webauthn authentication is sufficient and password authentication is not necessary.
This is nosskey.😁 

 I need to do more research here. One question though - if nsec is encrypted by password then user would still have to enter it in the app, even if server only needs webauthn to return the encrypted nsec. So from user's point of view, it's still a second factor, even if server needs just one. Or am I missing something? 

 Mostly, you are right.
But strictly, it is not a password for authentication, but just an encryption key, so the user is only asked to enter it when changing browsers, for example.
This is because it is usually not recommended to store passwords in localStorage, etc., but with an encryption key it is considered possib le.

I think in bitwarden it is called "master password".🤔 

 Yes, hash of master password is used in bitwarden for server auth (since user already has to remember it to decrypt the master key), and webauthn can be used as a second factor. 

 My concern with The Nostr, unlike the password manager, is that implementing a master password like bitwarden would actually make the master password and nsec the same thing.
If so, users would have to worry about managing the master password instead of the nsec, which would not be fun.  

 I have the same concern actually. Here is my line of thinking:

Ultimately, user has to remember some secret (or have a reliable device storing that secret). Password can at least go through a hard key derivation function and be much shorter then the actual nsec and easier to remember. And w/ webauthn as a second factor, a leaked password alone can't be used to recover key from the cloud and decrypt it - user could be notified about the failed cloud access and be asked to change the password. 

I need to think more on this, I feel like there is still something here in what you're saying.