Replying to Avatar hodlbod

> 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?

The key is generated by and stored on the server, it never exists on the client. Other than the login flow, it's a normal NIP 46 nostrconnect flow. Probably a good idea to build permissions into the bunker, right now it signs anything.

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

Just UX friction, I don't want users to have to think about keys at all when they're getting started. Maybe I could do this after a week or something? Not sure.

> 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?

I considered this, and might still do it. It would definitely improve security. Building a re-authorization flow would also allow me to expire bunker sessions instead of let them live in perpetuity.

> 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.

Good idea, do you think we should shove it into nip46 or just let it be a separate thing?

> The key is generated by and stored on the server, it never exists on the client.

I said 'local keypair' in nip46 terms - the nip46-client keypair that will talk to remote-signer-pubkey. Anyway, you answered my question.

> Good idea, do you think we should shove it into nip46 or just let it be a separate thing?

Separate - the signup/login here seem only tangentially-relevant to nip46, and are HTTP endpoints (I guess?), not rpc-over-relays.

Reply to this note

Please Login to reply.

Discussion

No replies yet.