Oddbean new post about | logout
 The "Find Me" flow #nostrdesign
https://cdn.satellite.earth/a80993ff554f94cfb3a93b91a9580c7c0d130ccf222b4fd98ed6f12979d13e07.mov 
 
 I love this concept. Being able to seamlessly just “view” the world (or an app, or a place - in the case of Satlantis) through the eyes of another is very cool

And then choosing to log in (or unlock?) using YOUR keys, as and when you want, is a beautiful way to manage your access to applications 
 "Unlock" is some good language right there! Might use that 👀  
 I want people to discover this feature so much. I need them thinking "What if I click on this other Jack?" and then have their mind blown 😂  
 I love this, and read-only mode by default to try the app.

One issue with this is verifiers are shown by the app itself - so it could be faked by the app, and the More info can lead to a fake page that user won't discern from a valid zap.store page. Looking at verifiers makes sense only in a third-party independent app that you already trust (zap.store).  
 1. By default, I'd priotize opening that page in a native app the user already has or a web-based app he has some link with (zapped it, known app in his network, etc etc...)
2. By selecting who you are first, the app adapts the Verifiers it shows to your npub
3. I'm including Verifiers in my onboarding flow so that an onboarded user has an initial set of Verifiers (preferably independent from the app) like he would have initial Relays, Blossom servers or Mints.  
 What Arthur is saying is that 2. cannot be trusted.

The app could show you these icons of the verifiers without them having really verified anything.

 
 yeah, or like #nostrudel where it shows a verified badge but you have to click to the profile to see the domain associated with it

he added a color ring around avatars which goes some way but those things can be faked in about 2-3 weeks of vanity key mining, as well 
 yes, colors can be minted, and they are only useful to the extent you remember the colors of the people you are following.

I could probably remember 20 or 30, so not really useful. 
 The whole point of a follow is that you don't have to remember anything about them. 

That's why you literally bookmark them.  
 Colours are useful: 
- to find yourself
- to find someone new 
(I'm pippelina. Pink pippelina 😎)
- for imposter detection services
(If pfp, bio, last digits of npub, color, ... match with an earlier created profile) 
 creation date for npubs can be faked as well, unless they are using Open timestamp or something like that.

And even if they couldn't be faked, they don't mean shit, because I can create Apple npub

 
 i think color, last 6 characters of the pubkey, and the nip-05 URL should all appear right next to the display name always 
 that entails a pubkey grind of at least 2 years plus taking over a DNS record 
 Good Imposter detection + removal goes a long way. 
(will probably some kind of timestamp yes)

No way that I'm showing anything more than Display Name  +  Following/Not icon on 95% of screens.  
 Yes, I know. Every app can fake everything. 

That's why I think a verification button that opens the same data set somewhere else (that you already know) in the onboarding process is a good solution. 

It beats blindly trusting the app or centralizing "Nostr login" to a few honeypot services. 

A newcomer that is only part of Nostr group chat and then opens his first new app can do a loooot more with trusting the app he already knows and the Web of Verification that that app has, than with trusting who the other chat members are following.  
 fair. Public square dynamics (follows) aren't that useful if you aren't in a public square (e.g. a group) 
 “Social Onboarding” clients will fix the “first trusted app” problem. Simply by “inviting” their friends (from a client equipped in this way) to create profiles and “follow them”, Nostr advocates are implicitly “trusting” this client to faithfully present their (client and user and content) recommendations to the new users. 

In this way, any client that supports “Social Onboarding” (a web client with “invites” accessible via a shared link that creates a profile which “follows” and presents recommendations from the inviter) in a single “unbroken and trusted flow”, can act in this way as “first trusted client”.  
 That's ok, especially given the fact that onboarding a new user poses no risk for the newly created key - there's nothing valuable tied to it yet. My concern is when this flow is used to login to apps with existing valuable keys - you don't want to trust the app itself to show it's own verifiers.  
 I like this idea of “verified local key encryption”. Though this may be difficult to verify, having NIP49 implementation baked into a library will like NDK (so client code doesn’t NEED to handle the nsec at all) will be a good start. 
https://github.com/nostr-dev-kit/ndk/issues/216 
 Yes!
I'm not a dev and so I might be naive on the feasabilty of the verification. But it's the best trade of I can come up with for now. It works cross-platform and has way better trade offs than bunkers etc...  
 I’m with you on this… but we prolly gonna need more peeps interested if we’re gonna make “Key Encryption Great Again”. LMK how you fare.  
 Will do 🫡 
 yep, love. This seems like a super nice flow, especially for newer users. 
 Nice idea, I'll use this flow for my next chat app. 
 Native chat app!!??? Yes please 🙏