Thanks for exploring this space!

So basically when I "log in" your client will generate local keypair and pass it's pubkey into your bunker and it will accept it if the password is right and hopefully will only give permissions that your client uses - so if local keypair leaks at least hacker won't sign kinds other than ones flotilla uses. Is that sort of correct?

Why not send the ncryptsec immediately after signup to make sure user has the copy even if flotilla goes down?

Do you store keys as ncryptsec and if server is restarted all users have to re-login and key is only decrypted if user supplies the password? This would sound better than storing all nsecs encrypted with a single server-side key, right?

So compared to storing keys locally in the browser the benefit is that a) it works across devices, b) user can't lose the key. Seems like a good alternative to localstorage nsec - in both cases user kind of trusts that app won't mess with my key after I "export" it. Anything I'm missing?

nsec.app has an "import key" flow where you redirect to nsec.app with a nostrconnect string and nsec, nsec.app imports the nsec and connects the app using the nostrconnect string, so app can receive the nip46 connect ack and switch to pure nip46, all smoothly for the user. I have this implemented in nostr-login - user can create local keys and then export to nsec.app and their session is auto-switched to nip46. Would you use something like this if we standardize the flow?

We could also standardize the API of your bunker so that nostr-login could work with your bunker as a replacement for localstorage key flow.

Looks interesting overall!