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
Thread
Login to reply
Replies (62)
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.
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?
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!
ππππ
looking forward to reading it!
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 π«
He went insane many years ago; just mute and move on π
π₯π₯π₯ Let's do it!
Leaked footage of Pablo on the flight.
View quoted note β
Working on that Pablo stage schedule
ππππ
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.
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
Having a login option without mentioning npub, nsec and nsecBunker is a good idea but is this realizable?
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?
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.
View quoted note β
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
For Drupal there's already a NIP-05 module π
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

GitHub
GitHub - fabianfabian/nostr-media: Nostr Media Uploads for WordPress
Nostr Media Uploads for WordPress. Contribute to fabianfabian/nostr-media development by creating an account on GitHub.
What a beast.
Wen Pabloβs Unconference?
They're all Pablo's conferences π€£π€£π€£
As they should! π
OAuth via nostr using nbunker? Nice.
Do you envision it for business contexts or for casual users too?
Honestly Im not getting what makes this different than ZBD
View quoted note β
Was talking to @bumi 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
View quoted note β
Nostriches are coming back from nostrasia ππ


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.
Client C use NIP-07 or btfo π€£
View quoted note β
One of the best brainstorms about #Nostr, I read in the comments under this note. It's incredibly fascinating. ππ€β‘
View quoted note β
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
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.