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).

Reply to this note

Please Login to reply.

Discussion

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.