Oddbean new post about login | logout 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 @thenostrworld; 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. https://cdn.satellite.earth/2e2e353ac5f69caffdc73da81c4e735c19579432967323564924c585819e6ef9.mp4
This is slick
Very neat! Normie-lising nostr by actually making them power users with an nsec bunker is bad ass imo.
Putting your nsec into anything that's not open source and peer reviewed for security seems like a really bad idea. But I'll bite. Walk me through the key custody process from nsec entry to later retrieval @pablof7z. I found the repo for nsecbunkerd but is your client site open source? if so please provide a link. By the way on the nsecbunkerd github page it looks like you're storing the keys in plaintext with no file permissions set. Feel free to jump in here @hodlbod @semisol @broadmode https://m.primal.net/HRix.png
That thing you’re looking at is the testing client to send test events…
Ok thanks for explaining. Where is the repo that you used to make this site? https://nsecbunker.com/
Not public yet; we’ll be later tonight when I’m back home
Ok is it available now?
🤙
Nice workflow. I was thinking lately that new users might not understand everything about key pairs at the start. But could learn about it later. So in that case, a key pair could be generated for them. Later they transition to a self-sovereign key pair. There would need to be a way to keep track of this. I am already starting to look at versioning of profiles in #nosdav so that you dont lose your contacts list. If this were combined with a notarization event it would be possible not only to allow new users to take control of their own their identity, but also for existing users to rotate keys. There would be a fee for this (size of fee depends on security), but it is a path that could on board a large new audience.
It's really nice ! - But needs to be improved little bit. Why the whole setup isn't in one form? (No extra popup, that's a little bit confusing for the user) Maybe it would be better to do: Click login -> "choose your identity provider"--> list of nsecbunkers --> than the whole setup in one form
Fantastic work, Pablo. I hope we see nsecBunker support everywhere.
Awesome work Pablo, really neat and much easier flow. Thank you for the works 👋
cant wait to have this feature on nostri.chat please ! Eversince I added nostrichat to my legacy website , I have received at least five queries about nsec and stuff (log in) .. and eventually forced them to go anonymous .. and hence cant even reply to them :-) This would be a lifesaver . Last thing you wanna teach the world is a new way to "log in" .. That said , I do love the idea that nostr users understand the significance of npub and nsec ... I guess that should be reveled to users once they get comfortable with more compelling features of nostr such as zaps .. linking to gravatar is an awesome idea .. open and free ..
Amazing. I've tried onboardstr, but you're right, normies won't do key management. This OAuth style login makes nostr normie friendly. 🤙
"Second-party" solutions will enable onboarding the normies. This goes hand in hand with Fedimints; nsecBunker instances would make a great addition to their services Awesome work Pablo nostr:note1crl44xk24yc2ym5xlyyfjdeumxueyguzxetseg8r0prqzmqts47sghnmgp
nostr:note1crl44xk24yc2ym5xlyyfjdeumxueyguzxetseg8r0prqzmqts47sghnmgp Fantastic job by Pablo. The ever producing creative mind wins !
Passkey to nsec. Passkeys are going to be a norm may be in a couple of years.
Que faire pour obtenir enfin ce NUP05 et qu'elle extension est réellement adaptée aux mobiles ? Là où c'est très problématique pour les utilisateurs non issus de la Tech. J'ai dû investir sur le Bitcoin mais géré par mon ami techniquement même si tout le monde parle de gestion de clés savez que c'est fort compliqué entre nos autres préoccupations et priorités de gérer ses clés.. Peut-être je me trompe...
This mode doesn't require any extension and it's architected to work on mobile without any wizardry. The goal of this is to be a workflow that anyone who has been using the internet in the past year can feel very familiar with without learning a bunch of new things, specially when the payoff is not apparent.
Merci beaucoup Pablo de mon côté je peine à contribuer aux zaps nul n'a pas m'expliquer comment faire avec mon mobile et Getalby pour zapper j'ai noté que WSatodhi ne fonctionne plus sur les usa.. Lequel serait plus adéquat sur Android entre Zeus Bolt mutiny etc.. .. Il y en a tellement avec les publicités récurrentes de nostriches et clients en fonction d'1 objectif type sur une journée type que je m'y perds réellement et ne pense être la seule. Raison pour laquelle je ne veux point associer mes Bitcoins à mon compte nostr 🤨
Looks truly groundbreaking, but it seems like there could be serious key security concerns here... What's creating their nsec, & how is it being stored? It could also use some tooltip-style "this is what is happening" explainers throughout.
With nsecBunker, the key is encrypted on the client side.
I think this has the potential to change the way we think about network security. The ride or die freaks think about security differently from organizations. We are all about Szabo's famous quote, "trusted third parties are security holes," and take extreme measures to ensure no one else has access to our keys. A hospital or any other business has a gazillion people working for them that all need passwords, 2fa, etc. These are often smart people, but they know about as much as cybersecurity as I know about brain surgery. The way places deal with this is host files in the cloud with a trusted third party who has the most liability they can find. All the hashes of the passwords are stored in a central location, making them an easy target. From what I understand, this does the opposite. The keys are encrypted on the client, not the server. An attacker needs pysical access to the computer for the key. This mitigates the risk of social engineering attacks. If there is a breach, the key can be revoked. This won't stop nprmies from writing their password on a post-it under the keyboard, but that's okay. Most of the people in the office have a password of their own. It's still a bad idea, maybe a jealous co-worker finds your password and searches porn sites, but it's less likely to end up on the news. That's what I think anyway. Please correct me if I'm wrong. I am sure there are some things I've missed too.
Such an improvement in onboarding nice! Who do you envision will be the nsec bunker providers?
I think any client that sits at the top of the onboarding funnel it would make sense to run these things. I am planning on building a bunch of non-bitcoiner-focused apps that will leverage this. I think this would also make a lot of sense for something like @zach 's Flockstr to run (in fact, Zach came up with a username+password scheme as well but which the strings themselves compute to a key, so you would be essentially logging in to all clients directly with your nsec, which is why I think that approach is problematic, but same goal!)
Makes sense 👍 Is the the nsec bunker provider NIP-89 handler documented anywhere? Would love to play around with this.
Its quite simple really; It’s just a 31990 with a k-tag of the NIP-46 kind (24344 or something) and the 31990 profile data should have a _@domain as its NIP-05 that validly resolves to the pubkey that published the 31990. If you want to peak under the hood the fans site I showed in the video is already deployed so you can play around with what I used to make the demo video (although I’m not 100% certain that I deployed the most recent version)
No doubt this approach is the better way to go. From my experience onboarding people, they often love the idea of nostr but are left wondering what to do next. I think as nostr:nprofile1qqs8d3c64cayj8canmky0jap0c3fekjpzwsthdhx4cthd4my8c5u47spremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uq3wamnwvaz7tmwdaehgu3wwfjkcctev4ezuum99uutzdck suggests, we should rework the nostr.com site to be more of a normie onboarding tool than a dev-focused protocol explainer. Something that clearly outlines a bunch of example nostr usecases beyond traditional microblogging. If we could build in a great onboarding experience directly on nostr.com, that would be awesome.
パブロがまたなんか作った。 "ここでの私の目標は、新しいユーザーに以下を要求せずにオンボードする方法を作成することでした: * ブラウザ拡張機能をインストールする * 秘密をコピーする * npub/nsec の内容を説明する * 他の nostr アプリケーションとの相互運用性を失うことなく" nostr:nevent1qqsvpl66nt92jv9zd6r0jzyexu7dnwvjywprv4cv5r3hs3spds9c2lgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uq3vamnwvaz7tm9v3jkutnwdaehgu3wd3skuep0qythwumn8ghj7un9d3shjtnrv96hxetn9e3k7mf0qy28wumn8ghj7un9d3shjctzd3jjummjvuhszythwden5te0xy6rqtnxxaazu6t09uq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e5kuen09uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7ce3g8p
This is amazing!
Great PoC Pablo! As a best practice I would suggest to use only in-page modals, instead of popups; they are quite confusing and some browsers block them.
It can't be an in-browser modal though; it's gotta run in it's own domain. That's why twitter/google/facebook/etc all use a real popup for OAuth flows 😅
Oh right, the same-origin policy stuff! But you should be able to use modals at least in the process of the account creation, the more critical one, or are there other security concerns? Or mybe an iframe with a CORS setting on the provider side could be a solution.
Yeah, the account creation part where you enter the email and username etc is in-page modal, but then the password stuff must happen on the popup so the client generating the account can’t see it. It could be done getting absolutely everything in the client but that increases the trust significantly with the client and you also want the nsecBunker domain to have a cookie to authorize new keys without having to login. I’d say that would only make sense if the client and nsecBunker provider are the same entity in that case that would be fine.
@PABLOF7z you should put this great article by @Deleted Account on the homepage of nescbunker.com, it is a very useful introductory reading: https://njump.me/naddr1qqxkuum9vd382mntv4ez6a3jqgs87hptfey2p607ef36g6cnekuzfz05qgpe34s2ypc2j6x24qvdwhgrqsqqqa289pnwyp nostr:nevent1qqsvpl66nt92jv9zd6r0jzyexu7dnwvjywprv4cv5r3hs3spds9c2lgppemhxue69uhkummn9ekx7mp05r29s6
@PABLOF7z you’re always right on time. I don’t think I’ve ever seen a post of yours that wasn’t zap worthy. We are so lucky to have people like you, putting in the work, and making yourself visible and reachable to every pleb. It’s such a beautiful thing. Thank YOU Pablo.🫡
And yes, this work in mobile too! With no signer involved!
Extremely slow to decrypt messages, though. Or is it just me? New NIP-44 could send the shared key of the entire conversation back to the client instead of calling a decrypt function for every single message. That should make things a lot (10x, 20x?) faster. :)
Perhaps we can add a filter command to the NIP-46 RPC to fetch a bunch of messages and get them decrypted, so instead of the client fetching the encrypted DMs, sending them to the nsecBunker for decryption, and then back, the client sends the filter it wants and the nsecBunker replies with the messages directly. Or Perhaps we could have another approach where the nsecBunker is a relay, authorized clients AUTH themselves, publish to that relay and the nsecBunker/relay signs and publishes the event itself to the specified relays (added like a tag or something). And for decryption the client just gets the messages decrypted straight in the AUTHed wire.
Sure, or just change it from decrypt to getSharedSecret. That should already be enough to solve everything without having to turn the nSecbunker into a relay.
I’m struggling to see what would be the benefit of using an nsecBunker at all if the client is going to end up with the secret though, the only reason I would see is to share the nsec with a new client by leveraging this new auth_url response, but don’t know if such a niche user flow warrants this. Makes sense?
You are not sharing the nsec. You will be sharing just the sum (nsec+npub) of each conversation. In NIP-44 its impossible to calculate the original nsec just with the conversation key. Clients can then encrypt and decrypt messages but they can never sign for them. That's the role of the bunker.
Perhaps we can add a filter command to the NIP-46 RPC to fetch a bunch of messages and get them decrypted, so instead of the client fetching the encrypted DMs, sending them to the nsecBunker for decryption, and then back, the client sends the filter it wants and the nsecBunker replies with the messages directly. Or Perhaps we could have another approach where the nsecBunker is a relay, authorized clients AUTH themselves, publish to that relay and the nsecBunker/relay signs and publishes the event itself to the specified relays (added like a tag or something). And for decryption the client just gets the messages decrypted straight in the AUTHed wire.
Sure, or just change it from decrypt to getSharedSecret. That should already be enough to solve everything without having to turn the nSecbunker into a relay.
I’m struggling to see what would be the benefit of using an nsecBunker at all if the client is going to end up with the secret though, the only reason I would see is to share the nsec with a new client by leveraging this new auth_url response, but don’t know if such a niche user flow warrants this. Makes sense?
You are not sharing the nsec. You will be sharing just the sum (nsec+npub) of each conversation. In NIP-44 its impossible to calculate the original nsec just with the conversation key. Clients can then encrypt and decrypt messages but they can never sign for them. That's the role of the bunker.
Sure, or just change it from decrypt to getSharedSecret. That should already be enough to solve everything without having to turn the nSecbunker into a relay.
I’m struggling to see what would be the benefit of using an nsecBunker at all if the client is going to end up with the secret though, the only reason I would see is to share the nsec with a new client by leveraging this new auth_url response, but don’t know if such a niche user flow warrants this. Makes sense?
You are not sharing the nsec. You will be sharing just the sum (nsec+npub) of each conversation. In NIP-44 its impossible to calculate the original nsec just with the conversation key. Clients can then encrypt and decrypt messages but they can never sign for them. That's the role of the bunker.
Hi @PABLOF7z, I've pushed new version for improve nsecbunker support, you can download it here: https://github.com/luminous-devs/lume/releases/tag/v2.2.1 or update via Settings Screen I'm hope I can receive feedback from nsecbunker's author to improve it 😅 I'm also working to implement this demo for Lume nostr:note1crl44xk24yc2ym5xlyyfjdeumxueyguzxetseg8r0prqzmqts47sghnmgp
