Oddbean new post about | logout
▲ ▼
dtonon | 6 months ago (raw) | root | parent | reply | flag +1 
 You are basically describing NIP-46, but the private key never leave the provider, it is just used to sign the events. A particular implementation is https://nsec.app where the provider is actually the user's browser, so it's completely custodial.
▲ ▼
Erik | 6 months ago (raw) | root | parent | reply | flag 
 Makes sense. I've never been able to enjoy the nip-46 bunker setup. I love the idea, but the UX around having to change browser tabs (plus wonkiness in brave browser) leaves a lot to be desired for a mobile login usecase. 

I want to make an experience where basically a user can slowly "opt in" to more control over their key management, without compromising the security of their key.
▲ ▼
brugeman | 6 months ago (raw) | root | parent | reply | flag 
 This (slow opt in) is what we're working on now with nostr-login widget, signup starts with a local key and then when user has actually used the keys and signed something etc we'll be nudging them towards "key backup" - importing into a nip46 service etc. 

You're suggesting a new kind of service where user enters a password and app sends ncrypt to a server so that if local copy of nsec is lost (or they want to use another app) then ncrypt is downloaded, password is entered and nsec is again stored locally. Right? This kind of "ncrypt store" is actually part of nsec.app setup (we store ncrypt on server so you could "login" into nsec.app in another browser/device), but you're proposing to make it a separate thing. Sounds interesting. The problem of apps having raw access to nsec still holds, but at least you're not copying it around, and password can live inside the password manager. Still a step forward over "nsec login", I would say.