Implement `eip-6963` (multi injected provider discovery)

Keyrxng commented 7 months ago

Related to #215 (also relates to this)

I think it's time to implement MIPD but how it's implemented needs discussed first but below is why it needs done.

keeping up with the times
improve overall UX
improve mobile UX greatly
ability to choose the wallet that you want to interact with the claim portal

Bob uses 2 different wallet providers MetaMask and Rabbi both of which he has installed as an extension on his desktop. Bob wants to claim using the Rabbi wallet but when connecting to the claim portal it's unlikely he'll be able to decide that as the two wallets compete for the spot in window.ethereum so he takes whatever he is given.

Next week he's on the move and wants to claim via mobile it's his first time and hasn't done this before. He tries safari, then chrome, then brave etc until he's googling stuff and in discord asking for help. Now he's forced to use MM as it has a browser and (for arguments sake) Rabbi doesn't but he prefers that wallet.

Mobile Specific:

mobile web3 is flaky af, most all browsers it shits the bed unless specifically designed for it an even then it's temperamental. The best way for it to work on mobile is deep links/universal links to the wallet app which is browser agnostic, and there are a host of mobile wallets that folk use not strictly MM.
If we do it ourselves it looks like a list of the top-supported maybe 3 - 5 mobile wallets (desktop we can display only the providers that are discovered via MIPD, on mobile they will not be 'discovered' we'll need to offer a default selection) but we'd also need to manually handle the deeplinks although WC do have an SDK for it
If we use a 3rd party option E2E, like walletconnect for example we can use their connect modal which handles all of the deep linking/universal linking connections, callbacks etc and has an extensive list of supported wallets out of the box

Desktop Specific:

I've implemented both as part of E2E testing but have only built tests for using the 3rd party modal and can revert to manual if that's the preferred option

styling can be adjusted ofc it wasn't a major concern for setup/testing

Manually

wc_manual

WalletConnect

wc_dark wc_light

EIP-6963

Keyrxng commented 7 months ago

Why it relates to this I believe is due to the following:

If it's the claim transaction that is failing which it appears to be then it's an issue stemming from the wallet provider not the RPC that is being selected by the RPC optimization functions. Those functions return a read-only provider and are only used to retrieve the balance and allowance of the funding address.
I'm not 100% on how the MM browser works exactly but I'd imagine it's MIPD compliant given their how-to-connect docs but either way the RPC that's used to send the TX is the one that is set within metamask.

0x4007 commented 7 months ago

I set as urgent because this directly affects usability of how easily contributors can receive payment for their work. Do you have a time estimate?

I really dislike wallet connect, or any of the existing UX. I think modern web3/wallet UX is horrible. I would like to implement something different.

To be honest, in regards to innovation, I would prefer to figure a way for a user without a web3 enabled wallet to be able to claim. For example, generating an in-browser wallet based on some webauth API etc. They can use on-device biometrics as a type of seed key. There's even a way to share the biometric seed across all iCloud connected devices (I've done with with logging into Cloudflare, GitHub, from iPhone and Mac.

Then, if we can reliably use your web3-rpc library, we should get fast RPC connections as well. Without any bloat from the wallet, we should be able to claim pretty much instantly after biometric auth etc.

This to me seems like a lot more sensible "futuristic" UX, but obviously requires a bit more research.

Keyrxng commented 7 months ago

I really dislike wallet connect, or any of the existing UX

Me too, I stopped doing Web3 things on mobile a long time ago because of it and my first time claiming from UBQ on mobile was in writing those tests.

To be honest, in regards to innovation

This issue I've opened would improve UX but I'm not 100% confident it would prevent the tx reverts, I'd focus on AA over this as if done right it removes the need completely for MIPD. So maybe close this as unplanned?

I will open a research task into account abstraction as what you've described is currently doable but will likely require either migrating Ethers to v6/upgrading to Viem and potentially requires smart contract deployment.

But aye if we were in control like this then we'd dictate the RPC_URL that the txs are fired to (without any jiggery-pokery) because we'd setup the client/transport not the wallet provider, I'd be more confident in AA as a fix to the issue as opposed to EIP-6963.

aa-sdk The aa-sdk is a type-safe and performant TypeScript library built on top of viem and fully compatible with ethers.js... The SDK implements an EIP-1193 provider interface so embedded accounts can drop right into popular app frameworks ... It also includes ethers.js adapters to provide full support for ethers.js apps.

Every smart account is controlled by an owner private key. A signer or WaaS provider securely stores the private key, authenticates access via email/ passkey ... Embedded Accounts are powered by the non-custodial Alchemy Signer API which uses Turnkey to securely store key material in a Secure Enclave so that only the user can access it.

Every request to Turnkey must be signed using a stamper. Turnkey supports multiple stampers including @turnkey/webauthn-stamper to sign requests with Passkeys

We don't have to go the full nine yards with AA either (see below) because the faucet covers gas sponsorship, batching isn't required (unless multiple permits to claim but permit-rollups covers those) either.

Web3Auth is an embedded wallet provider that allows users to generate wallets scoped to your application via Social Logins, Email OTP, or Custom Authentication Methods. This is great for enabling a better experience for your users. But ultimately these wallets are not much different from EOA's, so you don't have the benefit of Account Abstraction (gas sponsorship, batching, etc).

rndquu commented 6 months ago

@Keyrxng So we should close this issue as "not planned" since we're moving to the account abstraction and "user should be able to claim without web3 wallet" feature, correct?

Keyrxng commented 5 months ago

Yeah I believe so

ubiquibot[bot] commented 5 months ago

# Issue was not closed as completed. Skipping.

ubiquity / pay.ubq.fi