The "Find Me" flow #nostrdesign
https://cdn.satellite.earth/a80993ff554f94cfb3a93b91a9580c7c0d130ccf222b4fd98ed6f12979d13e07.mov
Discussion
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
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.
“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.
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...
yep, love. This seems like a super nice flow, especially for newer users.
Turns out:
- most normies hate this
- logging in as someone else (npub-only) is getting less interesting by the day