Nostr for Normies: The status quo of most of the internet is that of full-custody, with no way to exit, or a way to participate in the system if you don’t accept its irrevocably custodial nature. On the other hand we have nostr, which is the upmost self-sovereign system. But lit comes with the tradeoff of extreme personal responsibility of holding one’s key in an even more challenging way than Bitcoin (you can’t spend your nostr into a new key if your old key becomes compromised) Binary. This work introduces a new scheme, with its own tradeoffs, but one that can fill the gap to help onboard the next cohort of nostr users without asking them to jump through too many hoops. Learning the ropes of a new system is already challenging enough, asking new users to also learn about key management at the point of onboarding them is a very big ask with no clear benefit. But I don’t want to become a custodian of a bunch of keys! What if we allow ANY provider to become an interoperable custodian and allow people to choose This is akin to going from a single Wallet of Satoshi to thousands of @Fedi In light of this aim, I’m changing the license of nsecBunker to full MIT (from MIT+CC); I want it to be easy for anyone to offer this service.
PABLOF7z's avatar PABLOF7z
Here is a demo of a new onboarding flow for nostr applications. I started working on this after watching @rabble's keynote "Nostr for normies" at @npub1nstr...rg5l; which I highly recommend watching. My goal here was to create a way to onboard new users without requiring them to: * install a browser extension * copy/paste a secret * explain npub/nsec stuff * without losing interoperability with other nostr applications This flow resembles a lot an OAuth style (e.g. "Login with twitter") flow: * You create an account in one site (e.g. Twitter) * You can "login" to another site with that account * You can revoke access from using your account Behind the scenes this is using NIP-89 to find nsecBunkers that allow people to register an account in their domain. This means that any nostr application can offer a signup/login flow on any nsecBunker domain. The application itself doesn't take custody nor ever see the generated key. And what's cool is that any nsecBunker provider can create their own flow; they can use passwords, or not, they can require a payment or proof-of-work to create an account. They can brand their "signup/login" popup page in whatever way they want. Here is a demo video of this new building block that is now available to nostr applications.
View quoted note →

Replies (12)

PR incoming The only difference to the current is updating to ndk latest version and adding a signer.on(“authUrl”) to open the challenge url
🫡🫡🫡 Was already playing with an nsecbunker instance last week. But got stuck somewhere. Your work and especially this peace is pushing the boundaries 💪🏻
I'd love to help/see NIP26 adoption with hardware wallets or other secure key stores. Ensuring there is less need to transmit or otherwise handle long-lived irrevocable credentials is crucial.
NIP-26 is dead and should probably be marked as harmful and deprecated on the NIPs repo. I was an advocate for NIP-26 until I noticed how insufficient it is and how making it better has astronomical costs that would destroy nostr
What are the problems with it? Is it mostly solved by 46, or something else? I'm primarily concerned about that if identity is tied to a particular key pair, and that private key cannot be revoked or at least failed to renew without the public key changing, a bad client can permanently irrevocably compromise your "account."
karo's avatar
karo 2 years ago
as always Pablo doing cool stuff but as a "normie" I have no idea what the heck he's saying. keep on, friend! I need more knitting and baking friends on here. View quoted note →