Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Last week I was in Berlin for the blockchain week. It was a great opportunity to catch up which the community and present the latest work from myself and iExec. I expected heavily developer-focused events, like the Metacartel Demo day and the Ethereum-magician council to be inspiring, but I didn’t foresee how fruitfull they would be.
From the beginning of day one, Alex Van de Sande’s talk made it clear, my focus for the hackathon would be on improving the login experience. I later realized that Chris Whinfrey had been thinking about something similar for a while; it was high time to team up and get coding!
A year ago, when you wanted to use an ethereum app, you had the option to go to MEW and give an encrypted JSON with your private key (or giving it your private key directly which is even worse) or using Metamask. Metamask was (and is still is) great for technical users, but it is still a major pain point when onboarding. You need to understand what a seed phrase is, having to write it down before storing it in a secure place. You have to copy it to each of your devices (which is a security issue).
Surely, we can do better than this!
We did build other options for less technical users, however. Gnosis Safe, Argent, Portis, Authereum, Torus, Universal Login, Abridged, Shipl … there are so many, I’m sure I’ve probably missed some. But on the other hand, when I want to use an app, it often only supports Metamask. Which is sad if you want to send a cryptokitties on opensea.io using Torus with your google account. That’s not really a trending DeFi application, but it is still a use case that should be addressed.
So what do we do? Do we ask certain app developers to add support for more wallets? That would be great, except all apps would have to go through the same painful process and it is unlikely that they will do the effort for small wallet providers. If you believe that a user should be free to use any wallet on any app, this is not the way to go.
Wallet connect is a move in this direction but we think it does not go far enough (and is partly centralized).
First, we want users to be able to use any wallet on any app. Adding support for new wallets should be a decentralized process.
Second, Adding new wallets should be transparent to the app developer. With the ENSLogin system, their app should be instantly compatible with all wallets, event those that the app developer doesn’t know and those that will be developed in the future.
Last but not least, the user shouldn’t have to know about wallet providers. If you have the choice between 5 icons you might recognise the one project of your wallet is based on, but when there will be 20 or more, this will be much harder. If we want to onboard hundreds of millions of users, we have to find a better way.
The question starts with “how will users remember the address”? Hex strings? I don’t think so! I personally don’t remember my address by heart. What I remember is my ENS address, hadriencroubois.eth, which I can simply tell to anyone that wants to send me something.
So let’s use ENS addresses. Let’s give addresses to all our users. Do you have a Portis account? You should have a .portis.eth address at some point! Same goes for all the other providers. Some already do, and in the future most projects will propose addresses to their users.
But ENS is much more than just Ethereum address resolution. It can also store metadata. For example, pricefeed.doracle.eth resolves to an Ethereum smart contract, but also to a decentralized website stored on IPFS. We can use that to store details about a user’s wallet, such as which provider to use.
When connecting, a user is asked for its username. The ENSLogin SDK will look for metadata attached to this username, or, as a fallback, to metadata attached to the parent domain. This metadata will point to a javascript file on IPFS or SWARM. The SDK then downloads the file, and use it to generate an ethereum provider. This provider will be passed to the app, which can then use it to interact with the blockchain.
Loading the provider-specific logic is transparent to the app developer. If a new wallet was to appear, if the provider puts the access logic on IPFS or SWARM and the required metadata on-chain, then all apps will instantly be compatible.
This makes ENSLogin transparent to the user, and transparent to the app developer. All the work is done by the wallet provider, which only has to do it once for all its users to be able to connect to all apps.
This is what we implemented at the hackathon. In just a couple days we built the core, modules with support for Metamask, Ledger, Portis, Torus. Authereum (is on the way but still has some minor issues). We also built some frontend to show potential use cases. The demo is available here.
This demo runs on the ropsten test chain were we configured the enslogin.eth domain. You can connect to a specific wallet using the dedicated entry points:
Since the hackathon, I have started improving and cleaning up the code. What we built over the weekend is still not quite production-ready.
For a good integration with apps, we must also standardize some features in the ethereum provider. For example, ERC1102 introduced the “.enable()” method (now replaced by the “eth_requestAccounts” rpc call). Similarly, I believe we need a “.disable()” method that locks the provider. This is a feature that already comes with some wallets but is not standardized.
We also need interfaces for the app to ask the provider to switch chain or switch account.
The good thing is wallet providers are showing interest in being part of ENSLogin, so this will give them incentives to implement these upcoming standards.
I already secured enslogin.eth on mainnet. I plan to give control over the relevant subdomains to wallet provider projects.
In the web2.0, access authorization is often represented by JWT (JSON Web Token) that contain a small piece signed of data.
For Web3 to provide the same functionality, we could imagine replacing the traditional JWT with new ones based on ethereum signatures. Signing an access token would be as simple as connecting using the ENSLogin logic and have you confirm the signature depending on the wallet security. No need to know which wallet you are using, just type in you ENS username, follow the wallet specific (and hopefully short) instructions, and boom, you are logged in to any service!
The fives hackers from this weekend are Shane Fontaine (Authereum), Miguel Mota (Authereum), Tom Teman (Portis), Chris Whinfrey (Authereum) and myself Hadrien Croubois (iExec).
Many more are interested in the project, and we are in contact with members of almost all wallet providers as well as members of the Ethereum and ENS foundations. The strong incentives for both the apps and the wallet providers to have this become a standard makes me optimistic, but like all other standards, it will take time to make things right.
Maybe next year this is how I will connect to remix.ethereum.org, opensea.io and manager.ens.domains
Others post on that subject:
Interested in following the iExec project? What’s next?Before iExec V4 (the high-performance computing version with GPU support) is released this year, we’ll be giving more news on the recent developments of each of the recent announcements. To be the first to know and get exclusive updates, subscribe to the iExec newsletter and follow on social media.
The iExec team is reachable on Slack, Gitter or Telegram. You can subscribe to our newsletter to be the first to know about announcements news and community events.
Telegram • Twitter •Youtube •Github • Technical Documentation
