When we started building Parity Fether, with a tiny team of developers mid-2018, our only goal was to push forward the development of light clients. We believe that light clients are a critical piece of infrastructure to build web 3.0, a web where decentralization, censorship resistance and self-ownership of data matters. As discussed in depth in a previous article, light clients are critical because they allow developers to build apps that work in a fully decentralized manner without having to sync the full chain.
In order for our light client to best meet the needs of developers who will build on it, we decided to try building an application on top of our light client ourselves. This is why we built Fether, a wallet based on the Parity Ethereum light client.
Parity Fether is a wallet in its simplest form. Big efforts have been made to make the user experience as good as possible. Although the installers of Fether for Mac, Windows and Linux have been downloaded several hundreds of times, getting feedback on an alpha version remains a challenge. Because the application does not embed any sort of tracker, performing user studies is the best way we have to get a feeling of what users like or not and how the application is being used. In the spirit of open source, I consider it extremely important to share the findings among the community so that anybody can benefit and learn from the work of others.
We launched the first alpha version of Fether in October 2018. I reached out to my network to gather feedback. This article is about the findings this user research provided and how it changed the way we built Fether.
About the testers
I interviewed just over ten testers. While this could feel like a low amount of testers, this user study focuses on qualitative analysis. Because the population of testers is neither big enough nor representative, you will not find statistics in this article. The study took the form of a friendly conversation and the goals were to understand better how and why users interact with Ethereum wallets and try to figure out their needs and feelings while using Fether.
Each tester has been in the crypto space for over a year and uses wallets for Dapps testing/using, gaming and trading. A vast majority owns 5 to 10 different tokens and about half of them own at least one NFT. I focused my questions on their personal use of wallets, although they work on wallets or use some very regularly in their day to day work.
All the testers use desktop wallets and most use a hardware wallet as well. What came as a surprise to me was that almost half of them do not use any mobile wallet. They didn’t express the need to have their crypto assets with them at any time and the threat of having their mobile stolen or hacked and potentially compromising their private keys kept them from using a mobile wallet.
Almost all users I spoke to use Metamask to browse Dapps. In their own words, they use Metamask because it is always in the browser and handy to open, also all Dapps support it and usually promote it. However, the testers that were concerned about security didn’t like the fact that their funds are tightly connected with their browser. Therefore they only used Metamask for smaller amounts of money.
Seamless light client integration
As mentioned before, Parity Fether’s major benefit is that it runs its own Ethereum node in the background. It does not rely on a third-party to access the blockchain. While this makes the software very resilient to censorship, it adds an extra step to the onboarding process. In my conversations, it appeared that downloading and starting Parity Ethereum node upon Fether’s first launch happened in such a seamless manner that this extra step has barely been mentioned by testers. Depending on the testing period, the sync of the chain lasted up to several minutes. While this could feel long, testers focused on creating or recovering an account while the light client sync happens in the background. The wait for the sync happens only at the first launch, and that was well understood and accepted among the testers.
Although the experience was seamless, we would like to reduce this waiting time. Fether in its future version will be a taskbar app. It can be launched at computer startup and will therefore always be at hand, and in sync when needed.
Once the Ethereum light node gets to the top of the chain, the users are able to see Ether and ERC20 tokens and transfer them. While using the application, the light client integration is invisible to users, there is no difference with wallets accessing Ethereum in a centralised manner. This seamless integration was made possible thanks to the use of light.js. Built by the Parity team, this React library was specifically created for applications that run on top of a light client. Like most projects we build at Parity, this library is open source and anybody can use it.
Usage of testnets
The interface of Fether is simple and clean: it pretty much only allows sending ETH and ERC20 tokens. The first alpha version has been released in Q4 2018 with several iterations since then. The v0.2-beta was launched in January 2019 taking into account the feedback gathered throughout the first months. Because we are still testing it heavily, Fether runs on Kovan network. For this reason, I found it interesting to understand in what conditions the testers interact with testnets. It turns out that the testers hardly ever use testnets. When they do, it’s either because they develop their own Dapp or because they really want to test a Dapp that hasn’t launched on mainnet yet. Because of this, there is barely any use case for a wallet such as Fether outside of mainnet. Although this doesn’t sound like groundbreaking findings, it’s always interesting to validate such ideas. Fether will come to mainnet on version 0.3-beta.
Privacy and security
Using a light client to access the blockchain is what sets Fether apart. Unlike when using a third-party service, it becomes much harder to track the behaviour of users by linking their IP address to commonly-used Ethereum addresses. Also being free from centralized entity removes the threat of this entity being hacked. By using a light client, it is practically impossible as a user to get tricked by getting tampered data from the network or having their transactions rejected.
As an additional step to enhance our users’ privacy, we have changed the transaction confirmation links from pointing at Etherscan to Blockscout. For more background about why this move is more important than it appears, have a look at Peter Szilaby’s talk at DevCon 4 on metadata leakage. In brief, it is very concerning that a website which you constantly visit for verifying transactions can allow Google, Facebook or Twitter to log your browsing behaviour and eventually know information that you would probably not choose to expose to such services.
Among the testers I interviewed, the security of their wallet was the first of their concerns. As mentioned before, most users I talked to keep larger amounts of funds in a hardware wallet, making sure their private keys don’t reside on their computer. We have developed an application called Parity Signer that allows users to use a smartphone as a hardware wallet. The private keys are kept on the phone, which should never be connected to a data network, internet, or even to a computer. Sending transactions is made possible by using QR codes in combination with the phone’s camera.
Just like hardware wallets need software installed on a computer to access the Ethereum blockchain, Fether v0.2 can play this role with Parity Signer. Unlike other wallets though, your transactions are sent in a decentralized manner without relying on third-party services. You can keep track of your Parity Signer accounts as well as your more regularly used accounts all on one simple interface.
I would like to thank warmly anyone that has provided feedback on Parity Fether (I don’t give names for privacy reasons!) and allowed the team to make it evolve in the direction that matters to its users. If you have any question or comment, reach out to the team on GitHub, Gitter, Riot, Twitter.