During the early prototypes we had designs for dashboards, appstores, integrated code audit checks, identity as first class citizens, personal tokens, DAOs, prediction markets, and many other things that are only now started to see the light. One should not see this as “being too early” but as a sober reminder of how long projects take to mature. We couldn’t built most of these tools then, and we could only build a few of them today, because they depend on a more broad ecosystem. You can’t build it all in one day, in one team, and you should beware of anyone that promises you otherwise.

What we did wrong

Our lessons, summarized by Yan in two slides

Our biggest speed bumps were always mainly two: syncing a node and relying on Electron. Syncing a full node was doable in the early years, but soon became a chore that would take hours. These issues started being solved in 2017 when light client became reliable, and then in 2018 we also compromised and added a remote node (INFURA) connection that would seamlessly switch between nodes; we strongly believe the ecosystem needs a vast number of nodes being run by users. This issue led us to lose a lot of our early users who voted with their feet to use apps with hosted remote nodes. While decentralization and convenience are always constant struggles with both sides having downsides, it certainly something that can be fixed in the long term, with both mixed remote/local solutions like we used and with the advancement of light stateless clients. But this was not the case for the security vulnerabilities brought by electron.

Electron is a great framework for webapps on the desktop, built for apps that used their own trusted javascript files. But when you are building a browser, you are, by definition, running random code from unknown people all around the world. This is tricky. Also, for most of our history together, electron was not updated frequently and even when it was, it was still running several versions behind chromium, which meant that often the latest version of Mist was running an engine several months out of date. Google tends to publish vulnerabilities it found after six months of releasing a fix, and at that point we were still stuck with the one-hundred-day exploit open, leading to a situation where we were paying from our bug bounties fund from people who simply took known vulnerabilities in chrome and applied them to us. We had a professional audit of Mist and they were able to discover multiple vulnerabilities that were fixed, none very dangerous but in late last year we received notice of a few very serious bugs: ones that would allow an attacker to take control of your computer (and your crypto keys) by simply visiting an untrusted website. This is very bad.

We released a fixed version immediately, but then others similar attacks were revealed and at some point our own internal security team recommended that we not allow the user to navigate to untrusted websites — which is the whole point of a browser. We put an alert on the app and started looking for alternatives.

We explored many alternatives (like Tau, which uses Chrome Embedded Framework instead of Electron), but still we realized that the amount of human resources needed to keep and maintain a safe browser were far larger than our team could support.

Meanwhile, the ecosystem has also evolved a lot since the early years: Brave (which also started as an electron app but now moved to a full chromium fork) is a solid browser with crypto integration and a great companion to Metamask. In the mobile space, wonderful options were launched in the last couple years: ethereum native apps like Coinbase Wallet (formerly Toshi) and classic browsers vendors like Opera now have a web3 integration. This has lead us to believe that other browser developers have more resources and are closer to having web3 features natively, than we were of having a secure browser framework.

What nobody got right

We still believe there’s a long road ahead for the web3 vision. These are things that we haven’t seen done correctly by anyone so far:

IPFS/Swarm integration on the browser URL. Sadly, most ethereum apps still use traditional servers that don’t have the immutability guarantees of hash addressing content. If you are building an app or a wallet, consider hosting on IPFS so users can be sure the underlying code can’t change underneath them and break things. In our experience, this not solely the fault of browser vendors, but also an issue with the maturity of the underlying technologies: we successfully implemented swarm hosting over two years ago, but since then both the protocol and their network changed drastically. Sometimes being too early to adopt a changing protocol is a hindrance. Brave Browser is making good progress on this.

Sadly, most ethereum apps still use traditional servers that don’t have the immutability guarantees of hash addressing content. If you are building an app or a wallet, consider hosting on IPFS so users can be sure the underlying code can’t change underneath them and break things. In our experience, this not solely the fault of browser vendors, but also an issue with the maturity of the underlying technologies: we successfully implemented swarm hosting over two years ago, but since then both the protocol and their network changed drastically. Sometimes being too early to adopt a changing protocol is a hindrance. Brave Browser is making good progress on this. More use of ENS: we believe ENS (or other decentralized DNS alternative, like handshake) offer much better usability when it comes to adding addresses and domains. We have added ENS support to all our address fields in the wallet so you can use a name whenever you added an address. But in our experience, doing it unilaterally is not enough: you also have to provide easy ways for the user to register their own names, in a similar way that we launched token support by not only providing an easy way to add tokens, but also to create them. A good example of progress on this is Argent—inspired by Universal Logins (another project that came out of the Mist team)—which gives each new user their own username as part of the onboarding.

in a similar way that we launched token support by not only providing an easy way to add tokens, but also to create them. A good example of progress on this is Argent—inspired by Universal Logins (another project that came out of the Mist team)—which gives each new user their own username as part of the onboarding. Wallet is just another app, identity is not. We believe we made the right decision when we tried our best to make the wallet just another app on Mist. We also structured the app to focus on Apps that you keep coming back to, and not transient documents you read (which is why we always used sidebar icons instead of tabs for example). But we now realize that the real first class citizen should not be the wallet, but your identity. It’s important for any browser vendor to integrate identity in a way that is both private but universally accessible. This way you shouldn’t need to create a new identity on every app, and you should keep control of that information. For a good approach on keeping information private and yet portable, check the threebox project.

What now?

We are sunsetting Mist the browser and will no longer actively support it (but can revisit this decision for occasional security and fork upgrades), but a lot of our work in the past years will be reused, thanks to a great effort of modularizing and modernizing our own code. We are basically splitting Mist in multiple component pieces:

How we’re exploding the current codebase. Dotted are projects not yet started.

Node management : during the last year we revamped a lot of the internal node management of Mist and how it downloads and runs new versions of geth, swarm, whisper etc. We are now working to release that as a separate app to help developers manage multiple versions, called Grid .

: during the last year we revamped a lot of the internal node management of Mist and how it downloads and runs new versions of geth, swarm, whisper etc. We are now working to release that as a separate app to help developers manage multiple versions, called . Reusable React UI elements : we carefully rewrote most of our components in a reusable library called “Ethereum React Components” that can be used as a starting point for other apps. You can check them all live on our storybook.

: we carefully rewrote most of our components in a reusable library called “Ethereum React Components” that can be used as a starting point for other apps. You can check them all live on our storybook. Confirmation windows : we refactored the most important piece of the UI for a wallet, the transaction confirmation, in which the user must understand at a glance what’s happening. We are now working to integrate these interface improvements to Geth’s own key management app, Clef .

: we refactored the most important piece of the UI for a wallet, the transaction confirmation, in which the user must understand at a glance what’s happening. We are now working to integrate these interface improvements to Geth’s own key management app, . App update manager : we refactored mist’s self update mechanism in a general App Manager for unified update mechanism for binaries with hot updating and signature verification.

we refactored mist’s self update mechanism in a general App Manager for unified update mechanism for binaries with hot updating and signature verification. Package Signer: we also separated a different library that allows you to sign and deliver updates with nothing but an ethereum key, allowing projects to prove the validity of software in a more decentralized way.

we also separated a different library that allows you to sign and deliver updates with nothing but an ethereum key, allowing projects to prove the validity of software in a more decentralized way. Wallet: the app known as ethereum wallet is actually a webapp, usable by either mist or metamask at wallet.ethereum.org. That code is outdated and the user experience underwhelming, but we believe we can contribute with the Universal Login project in an open source non-custodial but safe wallet.