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

Reply to this note

Please Login to reply.

Discussion

Did you just fix Nostr?

I'm new to nostr...

Pablo’s special ability: Coding during a flight

* The Nostr

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.

Like it

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 nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 ‘s talk (I watched it on the flight): we need nostr for normies.

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

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

Pablo you are a machine 🫂💜🫂💜🫂💜

It doesn’t silo them.

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

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

😮 🤯

I fuckin love this! 💜🔥🦙

Take a third flight.

I will, about to board.

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

Cleaning up code 😅

It’s a short flight.

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

#Pablo4President

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

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”

Gotcha! Thanks for the explanation

Insane!

When does Alice meet Bob?

They had a fight. Bob stole all her sats

Oh my gersh rude Bob

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

Looks like DIDs. :)

We’ve come full circle ⭕️

hahahhahha

I’m just pretending to understand what was written here.

i just skip over the NIP numbers as It won’t resonance anyway, without actually knowing them

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

😂 but does alice get it!

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

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

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

nostr:note13769695dhxwkjq4jmjcfd2g0vuzmwlkpl5h9ggs5upr2mm805ddqgugnkj

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

That’s the goal!

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

It is

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.

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

https://github.com/fabianfabian/nostr-media

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?

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

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.

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.

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

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.