FLIP 316: FCL Ethereum Provider for Cross-VM Apps

[jribbink]

Closes #316

[bluesign]

I think here also fail case should be ok

[bluesign]

( I don't know much of EVM wallet flow, may be totally wrong here. )

If I understood correctly, eth provider is injected after FCL login. But I think injecting provider before can be better option.

The flow I see on kitty punch, If I click login, it is popping up me a wallet selection dialog. Now if I add updated FCL I have to first login user with non-evm Flow Wallet to have provider in this list. ( I may be wrong on this assumption, but it seems provider is created on current user )

I think it may be better, if provider is in this list ( as we detect in discovery ) let's say BlueWallet ( hypothetical non-erm flow wallet extension ) and another provider maybe something like ( Other Flow Wallets ) which redirects to discovery.

So when I click BlueWallet it can directly authenticate with FCL ( extension pop up ) and I can use it transparently. ( via just initializing FCL )

[jribbink]

( I don't know much of EVM wallet flow, may be totally wrong here. )

If I understood correctly, eth provider is injected after FCL login. But I think injecting provider before can be better option.

The flow I see on kitty punch, If I click login, it is popping up me a wallet selection dialog. Now if I add updated FCL I have to first login user with non-evm Flow Wallet to have provider in this list. ( I may be wrong on this assumption, but it seems provider is created on current user )

I think it may be better, if provider is in this list ( as we detect in discovery ) let's say BlueWallet ( hypothetical non-erm flow wallet extension ) and another provider maybe something like ( Other Flow Wallets ) which redirects to discovery.

So when I click BlueWallet it can directly authenticate with FCL ( extension pop up ) and I can use it transparently. ( via just initializing FCL )

Thank you for the feedback @bluesign and I can clarify a bit on the timing of the provider creation.

fcl.currentUser() is a singleton describing the current wallet session that represents either an authenticated or unauthenticated state. (e.g. it is not a requirement that the user has already logged in).

Apologies if it's not clear in the proposal, but the intended use is actually as you describe: the provider is supposed constructed before the user has authenticated with FCL.

So for the KittyPunch/"Blue Wallet" example, it would be as follows:

1. Wallet-specific FCL Ethereum providers are created during the setup (these services would be fetched from FCL Discovery).
   - e.g. const bwProvider = fcl.currentUser().createEthereumProvider({...blueWallet})
2. These wallet-specific providers are now used to configure EVM wallet connectors for whatever library is used by the dApp. For Kitty Punch, ThirdWeb is used, so the for instance adding FCL wallets may look something like:

   // This adapter will instantiate providers using `fcl.currentUser().createEthereumProvider(...)
   import {useFclWallets} from "@onflow/fcl-thirdweb-adapter"
   
   const fclWallets = useFclWallets() // includes all wallets from FCL Discovery (e.g. Flow Wallet, Blocto, NuFi...)
   <ThirdwebProvider
         supportedWallets={[
          ...fclWallets,
          ...anyOtherEvmWallets
         ]}
   >

   (obviously exact syntax may vary, but critically, the dev would include FCL using an adapter/plugin)
3. The user would authenticate with the FCL wallet through the exact same "Connect Wallet" modal. When a user chooses "Blue Wallet" here, they're actually interacting with the FCL Ethereum Provider
   (thirdweb connect -> eth_requestAccounts for FCL Ethereum provider -> fcl.authenticate)

I'll see if I can make some diagrams & add a better description to make this more clear.

[bluesign]

thanks @jribbink for this is great explanation. It all makes sense now, I think this is a great idea and very useful for filling the current gap.

[bjartek]

Question: how do we ensure that evm developers are aware that they can perform evm method calls and use that result in a cadence transaction without the need to hit javascript in the middle.

Atm that is the world they are used to. Do some calls to get data then do one tx and then maybe some more calls.

[bjartek]

Will flow wallet use this new way if it used or their existing solution? Just wondering how to debug this.

[jribbink]

For apps using an FCL EVM adapter, yeah this would be the case. For those not using the adapter, they would continue to interact with Flow Wallet through it's integrated Ethereum JSON-RPC API.

[jribbink]

Question: how do we ensure that evm developers are aware that they can perform evm method calls and use that result in a cadence transaction without the need to hit javascript in the middle.

Atm that is the world they are used to. Do some calls to get data then do one tx and then maybe some more calls.

I think this is a necessary education piece which will also tie into @briandoyle81 's work.

As part of this effort, we would create some sort of exemplar application/guide in addition to any necessary reference docs. Existing documentation on Interacting with EVM using Cadence should be adjusted to highlight a clearer integration path for a prodcution application.