Skip to content
This repository has been archived by the owner on Nov 21, 2019. It is now read-only.

Check for web3 global variable, use it if available #238

Open
danfinlay opened this issue Oct 6, 2016 · 3 comments
Open

Check for web3 global variable, use it if available #238

danfinlay opened this issue Oct 6, 2016 · 3 comments

Comments

@danfinlay
Copy link

This is going to sound like wallet-ception, but bear with me, it might just be crazy enough to be cool.

I'll illustrate by describing a user experience:

I'm a Mist/MetaMask user, and I hear about some cool new feature that was added to MyEtherWallet. It's a voting tool for some important upcoming fork or something, I donno. I click a link to MyEtherWallet.

Normally at this point, MEW would show a "create a new account" screen, but in this alt-world, MEW instead does a little web3 check before assuming no wallet, like this:

if (typeof web3 !=== 'undefined') {
  var userAccount = web3.eth.accounts[0]
  initWith( userAccount );
} else {
  // Start MEW as usual...
}

When it identified a global web3 object as present, rather than suggesting creating a new account, it just proceeds to the normal, full-featured MEW interface, with that account available to it.

The hardest part would probably be swapping out the key-signing you're currently doing, since the web3 api actually makes it a lot easier, any call to sendTransaction prompts a user signature request within Mist or MetaMask (you don't need to touch private keys with this API).

As a MetaMask/Mist user, this is awesome, because I just got to enjoy the MEW UI without having been reliant on it as my previous key manager.

For MEW, this might seem more dubious, since you damn near support any account type already. Well to this, I have a few things to say:

  • Your UI is awesome and stands on its own, so rather than worrying about undermining your key signing, maybe this is a cool way to elevate your "ethereum home page" status.
  • This alleviates load on your backend, since Mist/MM users bring their own blockchains.
  • Both MetaMask and Mist are planning on adding more and stranger key-signing methods, hardware wallets, weird contract wallets, and if you embrace the web3, you get all that for free in your UI, you leverage the work we do in key signing. #BetterTogether

Anyways, that's my pitch. I know it's pretty far off your current core feature path, so I'd understand if you shave it off as not a priority, but as a Mist/MM user, I think it would be cool.

@tayvano
Copy link
Contributor

tayvano commented May 23, 2017

@FlySwatter HIIIIIIIIIIIIIII!

(not urgent at all)

So we're making lists and stuff and I was wondering if you envisioned the broadcast via Metamask or via MEW? (remember the token sales. remember the blame game. 😂)

We currently broadcast Ledger & Trezors via MEW so it would basically be the same flow, accept that instead of confirming on your HW wallet, you would confirm in Metamask.

@danfinlay
Copy link
Author

We don't really have a way right now for passing the rawTx back to the web UI (although I proposed a way to a new EIP over here).

So the way I had imagined it was definitely that MetaMask would be responsible for broadcasting these txs. This also aligns with how MetaMask allows users to select their own providers, and uses it, so if MetaMask + MEW were used together, the user could even use their own node at the same time.

I could see this being useful in situations like:

  • A user likes performance, so they use geth or parity locally
  • They use MetaMask b/c they use some dapps
  • They prefer a MEW UI for some service (Maybe ENS, for example).

In that case, it could be a pretty seamless experience if you just defaulted to using the injected web3.eth.sendTransaction method.

@danfinlay
Copy link
Author

Btw always fun to think about! I know no rush, we both have plenty of more important things as well, I'm sure, but it's cool how interoperable this ecosystem lends itself to being.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants