Replies (103)
👀
We should buy this man more flights.
View quoted note →I fuckin love this! 💜🔥🦙
#Pablo4President
* 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.
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
@rabble ‘s talk (I watched it on the flight): we need nostr for normies.
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”
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.
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 😂
View quoted note →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
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
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,
@rabble. 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)
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.
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.
View quoted note →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.
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 😅
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?
🔥🔥🔥 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
View quoted note →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.
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 →Wow 😳
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
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.
