Overcoming onboarding issues to bring dApps to the masses

There are already some strong efforts in the mobile Web3 browser/wallet space, including Status.im, the Coinbase wallet and the Trust wallet. However, these all still suffer from the same problems of being yet another app that needs to be downloaded and therefore continuing to provide an unfamiliar environment to the user.

As a simple example, most current Web3 mobile browsers don’t currently support landscape mode, and yet the dominant applications on the internet are entertainment apps designed to be viewed in landscape. Examples like Netflix or Youtube showcase the truly awful experience that consuming media or playing games in a Web3 environment is. Web3 browser apps need to improve their support for the internet’s most popular activities, and it can’t come soon enough.

These chronic hurdles lead to frustration and a poor initial experience for new users trying out what is supposed to be a ‘revolutionary’ new breed of application. The first impressions are terrible, and it shouldn’t be underestimated how much this is damaging adoption.

Better and more dependable wallets are coming, however, and some demonstrate real innovation, such as Argent, Tokencard, Dapper and Gnosis Safe. Some also enable easier onboarding that doesn’t force users to write down seed phrases, with security and usability powered by smart-contract based wallets that support spending limits, use relayers to pay for gas and provide social recovery of lost private keys. Despite this, these new browsers are still in their infancy. They are also challenging to find but do have a small but encouraging growing number of users.

We see the trend towards contract wallets as a positive one — and arguably Argent is currently the best of the breed but is only in limited release. Argent’s decision to pay for its user’s gas costs via its relayer is ambitious and probably explains why there’s a queuing system for user installs, but to afford to do this sustainably will require upselling value-added services to the user, and it’s unclear at this time how scaleable that model will be. Gnosis Safe is also impressive and is catching up fast.

Dapper Labs, creators of Cryptokitties, came up with their solution consisting of an app & contract wallet but doesn’t run on native browsers at this time, something that we feel is important to be able to reach the most significant potential audience.

Universallogin.io is another with an interesting approach, using ENS domains as usernames and is trying to gamify the experience of creating an account by rewarding achievements. It seems somewhat similar to Argent in its goals but not as far along in its development.

One issue we’re aware of with contract wallets is that they require some on-chain transactions to create the ENS username and contract wallet which adds a small delay and cost to the initial creation of a user account. These transactions are subject to network delays and fluctuating gas costs, which someone somewhere will have to pay for. Many of the contract wallets also rely on relayers or guardians and its not clear who pays in that instance, or what relayers have to charge to operate their service in a sustainable way.

Some of the demos we’ve seen so far are running on test nets or side chains which operate faster and are less expensive than ‘main net’ and aren’t quite as representative of the real world where the network can become clogged by uncles, airdrops, kitties and ICOs, which might not make the experience so frictionless for a first time user.

Long-term we have high hopes for these and other new contract wallets, but in the meantime, a couple of billion people are using existing browsers and only single-digit thousands have downloaded these new Web3 browsers and wallets. To reiterate, anything the user doesn’t already own and use on their phone is ‘high friction’ and will put headwinds in the way of dApp use far more than if the dApp could somehow run on their existing browser without any download or requirement to install a new plugin or browse or wallet.

Other initiatives like WalletConnect are exciting and might be a temporary bridge to connect wallets with existing browsers, but these too are complicated and not particularly user-friendly. QR codes to bridge a wallet and dApp are still unnecessary friction.

We’re also interested in what Austin Griffith is doing with Kirby, allowing for instant onboarding via an ephemeral private key, which might work well for low-value use cases that don’t require much security, and we’re keen to see how it will cope with the security of running in an iFrame and not allowing a rogue parent site to steal user funds.

One additional problem facing all of these specialised mobile browser apps is potential App Store censorship. Both Apple and Google have a chequered past when it comes to arbitrary censorship of apps, especially those that are related to crypto (potentially eating into their current or future banking and credit card business models). This adds considerable uncertainty to the dedicated crypto mobile wallet/browser.

An example of this censorship had already happened in the EOS ecosystem, where a popular browser/wallet was taken out of the app store for offering discovery features of available dApps and was only allowed back in when the dApp discovery option was curtailed.

If we want to be able to onboard new users, en masse, with as little resistance as possible, we need our dApps to run on whatever browser the user already has, on whatever device they’re already using. The mountain must come to Mohammed.

How can we make dApps run on standard browsers on any device, you might ask? By building a bridge between the Web2 and Web3 worlds that will enable new users to quickly try our dApps using the devices and browsers they already own.

Our FunFair B2B-focused gaming tech launched almost a year ago allowing games of chance (provably fair) to be played for real money (in our case, through the use of our ERC20 FUN token) and is now available on a couple of initial sites with more coming.

During that time, we’ve collected scores of anonymous data points on where the user gets stuck in their onboarding journey. We can see plain as day where we lose people in the onboarding funnel, and much of the time its very early — at the start — the moment they’re asked to download a Web3 browser or wallet and to create an Ethereum account. We believe we could reach a lot more users for our dApp if there were far lower friction, no requirement to download or install anything new, and a UI that had a much more comfortable learning curve.

While we are first and foremost an online gaming platform company, we recognised the critical need for this ‘newbie friendly’ approach and decided about a year ago to embark on building our technology to provide an easy to use wallet that targets this significant onboarding friction.

Our FunWallet runs in any web browser inside an iFrame, on any device, mobile or desktop, Safari or Chrome. No plugin nor download nor install needed. Nothing to seek out in the App Store. Nothing that risks being censored by the App Store gatekeepers. So thus our users will now be able to run any of our partner casinos within their own comfortable and familiar environment with a smooth user journey.

While security is always front of mind for us across all elements of our ecosystem, we needed to make some tradeoffs between strong security and user familiarity and convenience. Every wallet needs to determine where they balance these two factors, and we think we’ve come up with a robust security offering, but packaged in an easy to use — and most importantly — browser and device-agnostic manner.

We avoided going down the route of using a device’s phone number or using SMS as a way to securely identify a user as clearly this is a massive security hole that has been broadly exploited in other applications.

Instead, we’ve built a non-custodial web wallet that enables Web3 applications such as FunFair to run within a conventional browser by signing in to their account, using an email address and password. This is the same familiar way they already do in every other web application from Netflix to banking to crypto applications like exchanges.

Non-crypto people appreciate the familiarity of this approach, but we realise that crypto-maximalists might be concerned about using logins. The reality is that we’re trying to reach mass-market customers — who’ve never deliberately sought out crypto dApps.

It’s perhaps a trojan horse to let them use our dApps without ramming ‘blockchain’ jargon down their throats while reducing friction and finding a happy medium that bridges Web2 browsers to Web3 dApps. If these new users go on to learn more about blockchain and gain the experience and comfort to become ‘power users’, then we’re thrilled that it might help introduce some new users to our blockchain world of dApps.

As a result, the FunWallet lets any Web3 application run on the standard browsers that everyone already uses, including Safari on iPhones and Chrome on Android phones. It runs on Web3 browsers as well, thus serving the largest possible addressable market — which opens up even more ways for users to try our dApps.

Users make mistakes; They forget passwords, They lose or change devices. They get phished, scammed and hacked. So the FunWallet needed to support password changes, recovery tools, and support multiple devices and device changes, as well as optional security features like 2FA (but not SMS)! Moreover, of course since its Web3, it must let them export or backup their private key if they want to migrate to a different wallet in the future, and that’s one of the reasons why we’ll have MetaMask support at launch and others integrated down the line.

Our security model has similarities to some secure password manager applications, Lastpass for instance or 1Password and Dashlane. It also has a resemblance to some existing and popular crypto wallets like Edge (formerly AirBitz) and Blockchain.com. It’s a non-custodial wallet and the user’s private key is held in encrypted form on the server, but the server doesn’t have access to the decryption key. The private key is only ever decrypted locally in the client’s browser at login time from information that the user has provided (username and password) combined with a’ secret’ (we call it a ‘master key’) in their browser cache that is generated and stored locally and unique to each of the user’s devices.

The server never has access to the user’s unencrypted private key, in much the same way that Lastpass, 1Password and Dashlane don’t have access to unencrypted user passwords on their servers. Therefore the server is not a honeypot of private keys like some onboarding solutions out there — the server never sees your unencrypted private key, your devices’ ‘master keys’ (browser’ secret), nor the credentials used to generate the master key.

A year later and we’re no longer the only group working to bridge the Web2 and Web3 worlds via user logins and browser/device independence. Authereum and Tor.us are tackling this need as well, and Tor.us have a slightly different take on it, generating a secure private key using MPC distributed methods, but alas relying upon Google, Facebook and other 0Auth login methods. There’s good and bad in that approach, especially when it comes to user privacy as some would argue that these mega-corporations have too much information about us already and knowing when, where and why we login has significant downsides.

We’re keen to see lots of different experiments that help with onboarding, and we think the more options are tried out, the better it will be for all of us in the space. We can’t wait to see what they all come up with and how they approach the nirvana of frictionless user adoption, that’s fast, inexpensive, reasonably secure and which will become the most convenient and accessible.

Our short term goal is to work with the new FunFair wallet in a controlled environment. Initially, it will support just FUN and ETH and only work with FunFair-powered sites. We’ll learn from our users’ experience and tweak the wallet to do whatever we can to reduce friction and improve usability.