Thread

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 @🐈 @miljan @rabble

Replies (65)

No, the first client never sees the nsec. You’re only trusting the nsecBunker backend operator you use and with NIP-41 even if the bunker becomes malicious you’d have a way forward. Also, bunkers are economical actors and becoming malicious requires them signaling they are malicious. Keep in mind where people are coming from now, normal operations is you never can control your account nor have a recourse if the operator censors/revokes your access. This is a way for normies to compete with that state of affairs.
I meant the bunker. Just trying to understand from the perspective β€œtrusting a 3rd party is a security threat as a default”. They need not to be adversarial but just get hacked. We need easy-to-use solutions, and almost anything is better than centralised silos 😁 Farcaster’s Passkey was a nice implementation to make it easier for regular users, and also allowing to pay with Apple the reg&storage fees.
Woah that sounds amazing! Yea, would love to participate too, i have some ideas in mind, about the direction of a development like that. Also there are already happening a cool development around this, to use wordpress as media server for nostr
This looks very promising @PABLOF7z. Something like this would need to be deployed with a fully functional key rotation system. If somesite.com gets owned we are in a world of pain. But overall, I think you might be onto something big here for the normie onboarding use case. Of course the advanced option where people hold their keys directly always needs to be present.
I agree with some people here who are a little skeptical about the proposal. It introduces a new trusted third party, which is opposed to Nostr's spirit. Have you guys also considered an approach in which the user generates a key pair (account) in every new app and maps the accounts together as belonging to one identity? Losing one key can be handled by making it invalid through a voting process achieving a certain quorum. In a similar manner, the user can add new accounts to his identity by voting for it with existing accounts and reaching the required quorum. I imagine the new protocol can define events of new kinds for account mapping requests, approvals, and rejections. There are some open issues with this approach, for sure. How we can minimize attack vectors and handle the fuzzy state inherent to Nostr? But I think it is worth exploring such an approach too. With this approach even browser extensions aren't needed, replacing trusted third parties through a consensus protocol. Do I miss something fundamentally wrong here? I'm looking forward to your thoughts on this.