how are keys handled?
on the second flight I finished writing the implementation (and modifications to NIP-46) to make the following possible:
1. Alice goes to App A (e.g. Coracle) -- she clicks "create account" and gets a NIP-05 "alice@somesite.com". She uses Coracle as she normally would.
2. Alice goes to App B (e.g. Primal) -- she clicks "login" and types in "alice@somesite.com". A popup comes up and asks Alice if she wants to authorize this application to access her account. In an advanced setting She can scope down what the application can do (e.g. only create short notes but don't change the profile data)
At no point is there any mention of nsec, npub, keys, NIP-07, nsecbunker. Nothing. It just works.
cc nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240
Discussion
Nip 46 and each app gets its own local key. The first app that generates the user’s key gets auto approved, subsequent ones need user approval.
When the user wants to off board from whoever is running the nsecBunker backend they can NIP-41 rotate the key away if the nsecBunker becomes malicious.
The cool thing is that downloading a “recovery kit” is already a very normal flow from apps that have important data; and this could provide a “Recovery kit” that includes everything the user needs, including a NIP-41 identity migration scheme.
This work was largely inspired by nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 ‘s talk (I watched it on the flight): we need nostr for normies.
This is awesome. Definitely cleaner than my solution of concatenate and generate a key and hope the user never forgets their email+password 😂
It’s a nice idea and a great flow, but it suffers from some problems:
Low entropy
You are still giving your nsec to a million apps (here only one party has it)
No possibility of “password recovery” here recovery can be achieved