[FEATURE REQUEST] Replace copy/paste of public key with URL parameter to wallet provider
Describe the feature you would like to request
I would like the extension onboard to have fewer steps the user must complete.
In the alpha 1 release, the user must copy a public key from the extension and paste it into the wallet provider's website.
https://github.com/interledger/web-monetization-extension/assets/106775223/1a2527d3-cf01-4e6a-b94b-74296af99fbe
Describe the solution you would like
- User enters wallet address and taps connect.
- Extension opens the wallet provider's website with the extension's public key as a URL parameter.
- Wallet provider authenticates the user and saves the extension's public key when the user confirms they want to authorize the amount to use from the wallet.
Additional context
I'm not sure if additional information can be passed along with the grant approval. If not, then the desired solution would be to first confirm the user wants to use this browser for Web Monetization (as a way to approve saving the public key) and then the grant approval for the budget is a second approval.
While Interledger does not control the wallet provider website, but it could define a URI scheme as part of the wallet provider specification. Something like https:// (walletProvider.example/usersWalletAddress) /keys/add?key= (public key contents here). Because the key is a public key, it's fine for it to be passed as a URL parameter, where it might be included in server access logs.
Some related discussion in https://github.com/interledger/web-monetization-extension/issues/332 also (but about removing keys, not adding).
During Slovenia work week, I proposed a potential approach, which the team generally agreed with. As the extension can control web pages (and we already use those permissions), we can emulate user adding the key, without requiring manual copy-paste. We can add a button "connect keys" (or something) in extension which will do the automatic key addition - we still want it happening on user interaction only (though, goal is to reduce amount of interaction required). If we fail to add, we fallback to the current copy-paste approach. It's a bit fragile (wallets changing UI), but the happy path would reduce UX overload a lot. This would require some major rework on connect screen UI, so it may or may not make it to beta release, but we aim to do so.
I plan to discuss another (long-term) approach in today's Rafiki community call. But we'll likely go with above approach until/if all wallets support a standardized way.
From the Slovenija work week: the approach proposed at the top was agreed to be technically viable. However, @AlexLakatos said current wallet providers are not willing to do any additional integration work. The proposed approach remains a long-term option.
I do not support implementing extension-controlled user agent automation. Technical workarounds for business development problems should be a last strategy.
- The user would see flashes of page navigation and form input manipulation occurring, which could appear like someone was controlling their device, especially on lower end hardware or slower Internet connections.
- When wallet providers change their websites, they could break the onboarding without notice. This would require an extension update in order to fix. A fallback to the copy/paste method would prevent a full onboarding outage until an extension update rolled out, but this would then still require onboarding documentation to account for this scenario, which then does not achieve our goal of simplifying how much information a new user needs to be exposed to in order to get started.
- We could instead imitate the API requests the forms on wallet providers' websites use to not have visible page navigation, but this also is a fragile implementation.
Filed an issue for the long-term idea (https://github.com/interledger/rafiki/issues/2995). We've decided to go with the "browser automation with extension" idea for now.
Closing in favor of https://github.com/interledger/web-monetization-extension/issues/613