wevm / mipd Goto Github PK

want to play around on Next hehe, could we add this for SSR?

export function requestProviders(listener) {
    if(typeof window === 'undefined') return // <--- return on server
    const handler = (event) => listener(event.detail);
    window.addEventListener('eip6963:announceProvider', handler);

After applying ethui/ethui#352, I installed the Iron extension on my main browser profile (predicting something would go wrong, but testing for that was the point)

with both extensions installed, the first website I used happened to be https://app.charmverse.io/
took me a while to connect the dots with this, but the "Connect Wallet" (metamask) button is now redirecting to the chrome app store. disabling the Iron extension makes it connect to Metamask normally

Is there a way around this?
I'm assuming the long-term answer is that both a) metamask needs to support 6963, and b) whatever sdk is used by charmverse needs to be updated as well, but wondering if some viable solution is possible for legacy pages?

the EIP does mention that backwards compatiblity is supposed to happen (by still supporting window.ethereum) so maybe this is a bug / wrong assumption on whatever SDK the website uses?

I think it would be nice to have the ability in findProvider method:

findProvider({ rdns }) {
  return providerDetails.find(
    (providerDetail) => providerDetail.info.rdns === rdns,
  )
},

that would allow us to search for providers by "priority" or "conditionally".

I would suggest something like this:

const provider = store.findProvider({
  rdns: 'io.metamask' || 'io.metamask.mmi' || 'io.metamask.flask' || 'com.enkrypt'
});

This way the dapps would be able to pick their "preferred" provider which in some cases would be great to have. E.g. we are developing a MetaMask Snap and therefore our preferred wallet is MetaMask since others don't even support Snaps.

Thanks for reply!

The chrome extension that I write needs to sign transactions with wallets, most likely metamask.

I was wondering if you guys plan to support this use case?

What I basically try to do is to call store.getProviders(); from the content script injected into website (extensions thing) and get the actual providers, and then signs a transaction with them (if user is willing to accept it etc.)

As of now, the store.getProviders(); would return an array of 1 null element.