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


 ⭐ 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


Like it


I'm new to nostr...


Pablo’s special ability: Coding during a flight


how are keys handled?


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


I fuckin love this! 💜🔥🦙


Take a third flight.


I will, about to board.


It doesn’t silo them.

Maybe watch nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 fantastic keynote to get context on why this type of flow is important.


how can a remote third party who doesn't have your nsec sign on your behalf?


* The Nostr


how does it work without giving away your nsec or requiring a complex key delegation system and database?


🤣 what big problem is going to be tackled in this flight?


Cleaning up code 😅

It’s a short flight.


damn


I’m lucky if I can clean my tray table.  You da man


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?


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.

https://youtu.be/9pGZ2epF8ZY?feature=shared


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”


From: nostr:npub15a8nx85d5arqrvlasm929qmt7g2sgtvp6xfg5e7egcjh780znvps7nhd0k


i doubt he's going to like the requirement of caching people's nsec's or forcing a key derivation delegation scheme that complicates everything.


Insane!


When does Alice meet Bob?


Looks like DIDs. :)


I’m just pretending to understand what was written here.
https://image.nostr.build/b09a4f57252ab1915781ee54aa2a3f2dc45f0e00375e6276b72a3d8a9e96a9a3.gif


Gotcha! Thanks for the explanation


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


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.


i just skip over the NIP numbers as It won’t resonance anyway, without actually knowing them https://i.nostr.build/2A5d.jpg


The Language is very important- I like the word signature


We’ve come full circle ⭕


😂 but does alice get it!


maybe have Coracle have a separate authenticator app with pop-ups, doesn’t take up as many resources in the background


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


No, they don’t


hahahhahha


Yeah, we’ll need to work on communication and UX


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


They had a fight. Bob stole all her sats


Oh my gersh rude Bob


Where does the popup come from?


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.


I’m excited about this. It does add a bit of complexity for app developers but it’ll make nostr a lot more accessible.


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.


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, nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240. Thank you.


Neat! Damn that solves a looooot for the normies.
Time to start editing some signup flows 👌


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)


:heandbang:


Normal people don’t do extensions this way; it’s too high a bar


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.


Got it. NIP-07 is the end of key management UX and civilization has reached its conclusion. Have we arrived to the end of history?


HOW ARE YOU ALWAYS SHIPPING?!


Try to not waste time 😂

Often I fail at it


The man is a machine.


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?


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!


👀👀👀👀

looking forward to reading it!


it doesn't require app A open.

Is the same UX as using anything else on the internet, no weirdness. Just like a "Login with Twitter" opens an oauth window that doesn't require a previous version of twitter open running somewhere.


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


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.


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


No, really anything in nostr that has an API feel to it can be implemented in nostr as data-addressable. No endpoints, just pubkeys, so this kind of stuff will always feel a bit magical


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 🫂


Does that mean you need to trust the first key issuer and if they are compromised the rest is as well?


He went insane many years ago; just mute and move on 😅


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.


Leaked footage of Pablo on the flight.
nostr:note13769695dhxwkjq4jmjcfd2g0vuzmwlkpl5h9ggs5upr2mm805ddqgugnkj


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.


OK, makes sense.
Do you think the signup should then be to the nostr-connected server (which does not necessarily be the client) or should it always be to the client?

do we want to tell people to get a signer?


Working on that Pablo stage schedule


Bringing NIP-46 to life as you are is going to do wonders for Nostr and its safe adoption.


This is brilliant. Will really help with onboarding


We are the group who break (test) stuff after it’s made 😅


Having a login option without mentioning npub, nsec and nsecBunker is a good idea but is this realizable?


It is


That’s the goal!


So it's like the web apps are running the chrome extension without actually needing the chrome extension? 🙂 What is the security model - how does one app not steal everything?


When Bob steals all the sats, he becomes Robert! We shouldn't use friendly name for someone that steals sats 😅


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


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?


🔥🔥🔥 Let's do it!


I thought about this for some days. It's basically the open Id connect standard. Problem remains: If app B doesn't have the PK, app B cannot sign events. To achieve this, we need the relays to act as authorisation servers like in oauth2.


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?


What a beast.

Wen Pablo’s Unconference?


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


For Drupal there's already a NIP-05 module 😀


OAuth via nostr using nbunker? Nice.
Do you envision it for business contexts or for casual users too?


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.


Honestly Im not getting what makes this different than ZBD

nostr:nevent1qqsqwsev3yjctdz9erky4kcuaf4fjcppfr9r4wpm7k0fk6ndc0jpx6cprpmhxue69uhhyetvv9ujumn0wd68ytnrdakjuct4qgs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75srqsqqqqqp3w6w2e


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


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


Did you just fix Nostr?


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 nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft.

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.


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


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.


Client C use NIP-07 or btfo 🤣
nostr:nevent1qqsqwsev3yjctdz9erky4kcuaf4fjcppfr9r4wpm7k0fk6ndc0jpx6cpz9mhxue69uhkummnw3ezuamfdejj7q3ql2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqxpqqqqqqzg0kx6l


Wow 😳


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.


Blame it on NIP-05; that’s the only reason to use that, just a way to map a string to an npub


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.


Dude what


They're all Pablo's conferences 🤣🤣🤣


ayo


As they should! 😆


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.