Embedded Wallet

[mattlockyer]

2 Flows would significantly improve UX of Rainbow Bridge and ALL partner apps.

1. App creates user account

Use Case: Many apps want to faucet users, not send them to a faucet. But the app needs a secure way to get a public key (with the private key being in the localStorage of wallet.near.org domain).

Proposal: Embed iframe in app with exactly the same account creation flow we have now. User needs to select recover option for a new account. At the end, wallet.near.org iframe sends the public key back to the app via postMessage.

2. App embeds TX request

Use Case: Many apps don't want to redirect users to another page, which can be disorienting. Instead show a "drawer" modal sliding up from bottom of the screen to cover 80% height of app.

Proposal: Embed iframe in app with exactly the flow we have now for TX signing. Except instead of redirecting at the end, the iframe postMessage with the TX success.

Both Cases:

Doesn't need a redesign since we can use a full screen modal that slides from bottom of the screen (for example).

These can be done with special urls with ?embedded=true or something like this.

It doesn't add anything, just branches and updates how the wallet reacts when it's finished with those 2 flows.

We can "approve list" apps that embed iframe so we don't have bad actors.

[mattlockyer]

If we're worried about malicious iframes or iframe src URL manipulation:

If we load the iframe and user isn't logged in, we don't do anything and prompt them to visit wallet.near.org. e.g. we never ask for their seed phrase while embedded.

If we load iframe and there's accounts in localStorage, we can confirm TXs.

We educate everyone by having a banner that says "NEAR Wallet (embedded in app) will never ASK for your seed phrase!"

[stefanopepe]

Hey Matt! What's the timing for this feature? This can help to plan the work in advance and build the best we can given our available resources.

I can see the value of a "Plaid-alike" login flow, it is a key component for our ecosystem (see here and here) I can also see the value of keeping the users "nailed" to partners' onboarding flows, it's extremely valuable.

Let's step back from the solution design, focusing first on the goals:

• as a user already "logged in" on NEAR Wallet, I want to authorize a NEAR dApp without abandoning the current page, such that I can have an experience similar to Metamask
• as a user who doesn't have a NEAR wallet, I want to select my wallet name and authorize a NEAR dApp without abandoning the current page, such that I don't have to open another website and get lost in the process
• as the NEAR dApp founder, I want to measure and increase the conversion rate of my hard-earned users, such that my marketing and PR efforts have better returns

From a UX perspective we have various paths:

1. improve our existing redirection, e.g. adding a top banner with the name of the application being authorized, and sending the user back to the dApp page in case of any failures (let's call it the Paypal UX)
2. have a modal window, with a callable component/API, showing a smaller & simplified login UI on top of their existing interface (let's call it the Plaid UX)
3. have a mobile-based QR experience (see #16) where the user can login/authorize the dApp from the mobile phone. Similar to the Plaid one, but passwordless (let's call it the cross-device UX)
4. bigger stretch, add NEAR Wallet to Metamask (or fully support Narwallet) so the user can transparently use any dApp without even opening NEAR Wallet website (let's call it the Metamask UX)

All of them have huge pros and cons, but I think we can quickly narrow down the options, based on the desired timeframe. If it's yesterday, I believe we can't do much more than option 1

[vgrichina]

localStorage is not accessible from iframe, or to be more precise iframe gets it's own localStorage these days (because privacy)

This alone makes embedded wallet infeasible. Other than that we also shouldn't allow to embed the whole wallet (and/or transaction approval UI), as embedding app can easily trick user into clicking anything in given iframe by creatively placing some stuff on top of it.

We can do popups however for the cases when user doesn't have popup blocker active.

So I suggest we reframe this into something more feasible, but solving the onboarding problems described in the issue.

I see at least such alternatives:

• white-labeled account creation flow in wallet (both as just an entry point with config + as a separate deployable app)
• secure "offboarding" of app controlled accounts into the wallet after creation

[stefanopepe]

I prefer the second one: we have already the key rotation at the protocol level, and we plan in the medium term to have a structured SDK - which will enable applications to create wallets and manage airdrops/faucets as they like.

The first one (white-label flow) might create confusion around terms of service, support, and responsibilities.

[heycorwin]

@mattlockyer would love to hear your response to @vgrichina's points above whenever you have time.

[mattlockyer]

Ya it's probably impractical TBH.

But I would like the wallet login, create account and redirect flows to be much more programmable (as we've been moving in that direction).

Thanks!