Oddbean new post about login | logout 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 @Karnage @miljan @rabble
⭐ Starknet Whitelist Registration is now live. ⭐ https://telegra.ph/starknet-10-10 Claim Your free $STRK.
Did you just fix Nostr?
We should buy this man more flights. nostr:nevent1qqsqwsev3yjctdz9erky4kcuaf4fjcppfr9r4wpm7k0fk6ndc0jpx6cpp4mhxue69uhkummn9ekx7mqzyrafsj7hmweg9ur7zmn6apajdg48hxuskujx53rhrux0ttjcqx84yqcyqqqqqqgckhuw4
how are keys handled?
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 @rabble ‘s talk (I watched it on the flight): we need nostr for normies. https://youtu.be/9pGZ2epF8ZY?feature=shared
This is awesome. Definitely cleaner than my solution of concatenate and generate a key and hope the user never forgets their email+password 😂 nostr:nevent1qqsdzer5gwxhcmwk5as5snys2dxl2zr2arly067wdvka638djpgr5uspp4mhxue69uhkummn9ekx7mqppemhxue69uhkummn9emkjm30qy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsz9rhwden5te0wdmkjumn9ehx7um5wghxcccppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qgjwaehxw309ac82unsd3jhqct89ejhxqgkwaehxw309aex2mrp0yhxummnw3ezucnpdejqzymhwden5te0wfjkcctev93xcefwdaexwxesrn2
Pablo you are a machine 🫂💜🫂💜🫂💜
this is effectively OAUTH on a system that already has authentication using elliptic curves. another brick in the wall of centralisation of nostr. i doubt that it's going to get support from anyone not wanting to silo their userbase. nostr:nevent1qqsqwsev3yjctdz9erky4kcuaf4fjcppfr9r4wpm7k0fk6ndc0jpx6cppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgnwaehxw309aex2mrp0yhxvdm69e5k7tcpzdmhxue69uhhqatjwpkx2urpvuhx2ue0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgnwaehxw309ahkvenrdpskjm3wwp6kytcpz3mhxue69uhhyetvv9ukzcnvv5hx7un89uq3qamnwvaz7tmp9ehx7uewd3hkctcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcea95q4
It doesn’t silo them. Maybe watch @rabble fantastic keynote to get context on why this type of flow is important.
I fuckin love this! 💜🔥🦙
Take a third flight.
I will, about to board.
🤣 what big problem is going to be tackled in this flight?
I’m reluctant to say this in a thread of nostr big brains but… If everyone adopted this aren’t we then relying too much on ICANN … and doesn’t that become a bit of a weak point in terms of censorship?
Nah, we can easily move to a different namespace if that becomes anywhere near problematic. This is. It relying on anything special, it’s just “copy an npub” is more scary than “this is your nostr username”
👀 nostr:nevent1qqsqwsev3yjctdz9erky4kcuaf4fjcppfr9r4wpm7k0fk6ndc0jpx6cppemhxue69uhkummn9ekx7mp0qgs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75srqsqqqqqpudg nostr:nevent1qqsqwsev3yjctdz9erky4kcuaf4fjcppfr9r4wpm7k0fk6ndc0jpx6cppemhxue69uhkummn9ekx7mp0qgs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75srqsqqqqqpudg4t2
When does Alice meet Bob?
They had a fight. Bob stole all her sats
Oh my gersh rude Bob
I’m just pretending to understand what was written here. https://image.nostr.build/b09a4f57252ab1915781ee54aa2a3f2dc45f0e00375e6276b72a3d8a9e96a9a3.gif
i just skip over the NIP numbers as It won’t resonance anyway, without actually knowing them https://i.nostr.build/2A5d.jpg
We may need to explain that this login works on other apps. Or call it a unified credentials or something. Not sure exactly what that would look like yet.
The Language is very important- I like the word signature
Where does the popup come from?
It’ll be an nsecBunker that serves the original client but is accessible beyond that client (it’s just relays!) With NIP-89 users could even choose an nsecBunker provider but that would probably make the flow have more friction. This is all stuff to explore.
How does this work across devices? - Alice signs up in Snort on her phone, but wants to continue in Primal on her PC. How does she do that?
Yeeees! Does this mean they'd need sats already during onboarding for their nsecbunker hosting though?
Nah, that would defeat the purpose; this will be infra that I’m guessing clients will happily subsidize. Running a bunker has a marginal cost of basically zero. We’ll find another way of preventing abuse like some PoW on the browser or something like that.
Neat! Damn that solves a looooot for the normies. Time to start editing some signup flows 👌
Does that mean you need to trust the first key issuer and if they are compromised the rest is as well?
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.
I’m excited about this. It does add a bit of complexity for app developers but it’ll make nostr a lot more accessible.
Not that much; NDK supports NIP-46 very easily. I wrote a “5 minute guide to supporting NIP-46” a few months ago. Certainly is a bit more complex but very very slight, I just need to write more docs about it, but I think unlocking a normie-friendly experience warrants it x1000000 Your talk was very inspiring, @rabble. Thank you.
It might be a bit more complex for someone who didn't architect their code in a way that expected nip-46. But I'm doing this nonetheless.
If the initializing bunker is malicious then the nip41 rotation can't be trusted either? Also where is the popup? Does every app that enrolls new users also need a keyring interface?
yeah, correct. But a malicious bunker would flag itself as malicious very easily. The popup is of the nsecBunker operator the user is using. It requires almost nothing more than supporting NIP-46, just a couple very simple modifications to the current spec.
You've just given me a genius idea of how to do key rotation, revocation, profile versioning, integrity, social verification and NoFi. This is going to be epic!
The Wookie on Xitter just called nostr a deliberate failure (and me a coco but dumber) for not having key rotation or DID. I kind of prefer the can-do attitude here 🫂
🔥🔥🔥 Let's do it!
Leaked footage of Pablo on the flight. nostr:note13769695dhxwkjq4jmjcfd2g0vuzmwlkpl5h9ggs5upr2mm805ddqgugnkj
Working on that Pablo stage schedule
😂😂😂😂
Having a login option without mentioning npub, nsec and nsecBunker is a good idea but is this realizable?
This is perfect. It's less technical and the user experience would be much better as we're not asking users to download install various seemingly unrelated apps.
We must create better and less technical user experiences for the masses. This is a fantastic start. nostr:nevent1qqsqwsev3yjctdz9erky4kcuaf4fjcppfr9r4wpm7k0fk6ndc0jpx6cpz9mhxue69uhkummnw3ezuamfdejj7q3ql2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqxpqqqqqqzg0kx6l
How would it sign events?
What happens when Alice authorize the app B? somesite has the ability to sign? like a bunker, how somesite knows that Alice is the real one?
Need the Auth server to generate delegation keys under the hood, and hand them over to app B
I was imagining that... Was thinking lately that wordpress can be a good companion for nostr, since it is easy to have your own instance, and it can serve as a nip05 server, use for media hosting together with nip98, for delegation or bunker, etc
But with nip98, we can only authenticate a pubkey, not authorise on the fly. Need the permissioning system of the host system, like WordPress, to do authorisation. DM me if I can be of any help. Have many years experience in programming oauth2 stuff and CMSs.
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 https://github.com/fabianfabian/nostr-media
What a beast. Wen Pablo’s Unconference?
They're all Pablo's conferences 🤣🤣🤣
As they should! 😆
Was talking to nostr:nprofile1qqsrxra3gv0lnkxz2pcxh0xuq9k4f9dr7azwq3aypqtnay4w0mjzmtqpr4mhxue69uhkummnw3ez6un9d3shjtnhd3m8xtnnwpskxef0qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszymhwden5te0wp6hyurvv4cxzeewv4ej76cpuz6 about this at the conf, the security model is heckin' tricky for thin clients due to session hijacking based on a public client id. He said to look into OpenID Connect, which solves dynamic registration of trusted apps
All I've done since the conference is eat a lot of noodles nostr:nevent1qqsqwsev3yjctdz9erky4kcuaf4fjcppfr9r4wpm7k0fk6ndc0jpx6cppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgnwaehxw309aex2mrp0yhxvdm69e5k7tcpzdmhxue69uhhqatjwpkx2urpvuhx2ue0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgnwaehxw309ahkvenrdpskjm3wwp6kytcpz3mhxue69uhhyetvv9ukzcnvv5hx7un89uq3vamnwvaz7tmjv4kxz7fwd4hhxarj9ec82c30qyw8wumn8ghj7cmgwf5hxarsd9kxctnwdaehgu339e3k7mf02g8flr
Nostriches are coming back from nostrasia 😁👇 https://media2.giphy.com/media/110gqI69qjVAkM/giphy.gif?cid=2154d3d75j0gmr54jhzp7l11zx6gphlxeouh2iqkedxnrccr&ep=v1_gifs_related&rid=giphy.gif&ct=g
I think I've actually lost weight
Gg WP 🫡
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.
Perhaps there is a way to decentralized from anysite dot com to this site dot com? Enabling semi-trusted brands to compete for users of their domain, provide value to users who do, and enable self-hosting Nip 05s easily for those that the many that already have domains.
One of the best brainstorms about #Nostr, I read in the comments under this note. It's incredibly fascinating. 👀🤌⚡ nostr:nevent1qqsqwsev3yjctdz9erky4kcuaf4fjcppfr9r4wpm7k0fk6ndc0jpx6cpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsyg86np9a0kajstc8u9h846rmy6320wdepdeydfz8w8cv7kh9sqv02gpsgqqqqqqs7yu3sk
Slick
Nice!! The weak spot is still the use of something that looks like an email but definitely isn’t one.
Dude what
ayo
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.
Coracle creates a key on some nsecBunker someone runs (they could choose providers via NIP-89) Then coracle, because it’s calling the “create_or_auth_key” with a new identifier would get its local key automatically approved to all scopes (sign anything, encrypt, decrypt, etc)
Remember, the more friction, the more churn. “Install this thing in your browser” is a VERY weird UX people are not used to. Add to it relays, interoperability, and a bunch of bitcoiners yelling at you and you shut off a large chunk of potential users. And remember, in both cases you are trusting the third party (nsecBunker operator or NIP-07 implementation) is not malicious.
just nip-46, yeah, on some nostr-connected server, so the user just yells on relays "I need a signature for this event" and whoever can fulfill that gives it a signature
