Add ENS Support!

[okwme]

First off CONGRATULATIONS THIS IS SO COOOOOOL!!!!

Now that's taken care of, I want to use my ENS name! They recently included ATOMs in the public resolver & their app at https://app.ens.domains. I just went through and added my new keplar wallet address to my ENS name billyrennekamp.eth (as well as the subdomain cosmos.billyrennekamp.eth). They have a js library that should make it pretty easy to resolve addresses. I haven't checked exactly how to do it with records that aren't just etheruem addresses but should be similarly trivial.

Would be really great to see name service usability shared beyond Ethereum since it was built to accommodate any kind of records. Eventually we could see cosmos network offering subdomains when they start processing all TLDs (billy.cosmos.network would be so niiiice).

Similarly it would be great to see IOV name resolution working with star names!

I'll take a look now to see what else is needed to make this happen but I wanted to say congrats and make this an issue so the conversation around it could begin.

[cankisagun]

Congrats! The ability to create a metamask like experience on the Cosmos ecosystem is very important. At Enigma, we are building on Cosmos SDK and would be very interested to test Keplr for introducing new Cosmos SDK chains. We recently launched a testnet with CosmWasm and signing application specific messages is an area that's going to be very relevant, very soon.

We are also working on a coin mixer using our network called Salad. In mixers there's a lot of work also required on the wallet side for a smooth UX - users end up with more wallets if they want to properly maintain anonymity. We've done extensive research here and shared initial findings with the Metamask community.

It would be cool to think about wallet support for transactional privacy for the Cosmos ecosystem and explore potential areas of collaboration

Keep up the great work!

[okwme]

ENS = require('ethereum-ens');
cw3p = require('create-web3-provider');
namehash = require('eth-ens-namehash')
import { formatsByName, formatsByCoinType } from '@ensdomains/address-encoder';
const provider = cw3p({infuraKey: 'MySecretInfuraKey'}); // you can use infura as a free public eth endpoint
const ens = new ENS(provider)
const atomSlip44 = 118 // https://github.com/satoshilabs/slips/blob/master/slip-0044.md

async function getCosmosAddress(name) {
  const nameHash = namehash.hash(name)
  const cosmosSerializedAddress = await ens.resolver(name).addr(nameHash, atomSlip44) 
  return formatsByName['bech32Chain', atomSlip44, 'cosmos'].decoder(cosmosSerializedAddress);
}

getCosmosAddress('cosmos.billyrennekamp.eth').then(cosmosAddress => console.log)

I thiiiink this is what's needed? It looks like there are a lot of imports at the beginning, but they should all be the kind of minimal version of those libraries, plus the eth-ens-namehash is contained within the ethereum-ens library so webpack should be able to use the same one.

I've never used that eth provider library before but it looked like the most minimal i could find plus it's set to point to infura by default which is the easiest free node provider, you just need to sign up for a api key.

I haven't tested any of this yet, but I wanted to collect all the theoretical code in a single place before trying to see where in your code it might fit best.

[Thunnini]

I didn't consider this feature, but, I think that it is worthy to support ENS on Keplr and @dogemos loves this feature. I have tried to register my cosmos account to ENS and get the registered address from ENS in a manual way. And after this, I became to believe it is possible to implement an ENS on Keplr. But, it seems that ENS registration page doesn't support the Kava though Kava is listed on Slip44. This seems not to be a big problem, but it is an obstacle to users anyway. I saw that the wallet like Argent supports the ENS with subdomains of their domain (like tony.argent.xyz). I think it is economically better to support with subdomains of own keplr's domain because the maintenance of domain requests the 5$ fee annually but the subdomain doesn't. But, I don't know how to manage the subdomains of a domain yet.

I will make a plan to implement an ENS on keplr and I think there is no big problem on the technical side. But, research for user experience is needed because Keplr is software for normal users.

[okwme]

Awesome to hear! I agree that the goal should be to make this for normal users.

If you are interested in getting new coins added to the ens app, it should'nt be too hard to make a PR on this repo: https://github.com/ensdomains/address-encoder that will make the coin show up here: https://github.com/ensdomains/ens-app/blob/dev/src/constants/coinList.js

However it is also not necessary to use their app to create and configure different coins in the resolver. They are simply adding coins using this method: https://github.com/ensdomains/resolvers/blob/master/contracts/profiles/AddrResolver.sol#L38 where coinType refers to the slip44 number. This could be offered as a service within keplr if you wanted to go the route of providing a keplr specific subdomain. Furthermore providing free subdomain registration can be done using the following code: https://github.com/ensdomains/subdomain-registrar

One problem with this method is that the user (or keplr) will need to pay the transaction in Ether. There is some work being done on wildcard subdomains that might make optimistic registration possible: https://ethereum-magicians.org/t/eip-2544-ens-wildcard-resolution/4061/3 (altho eventually eth would need to be paid by someone still). It could be that you accept payments in Atom or Kava in exchange for paying the tx fee in eth? (I am also interested in using traditional DNS to register human readable addresses which would cost nothing at all)

It might also be interesting to consider alternative TLD from .eth. Currently only .eth, .xyz, .luxe and .kred are available to configure, although soon 99% of all TLDs will be able to be registered on ENS. This might avoid the confusion of .eth as being only for ethereum projects.

[dogemos]

Hey @okwme!

Talked with @Thunnini and wanted to give you a quick update on how we plan on rolling out the ENS integration.

We're hoping to roll out ENS integration in 3 phases:

1. Support sending to ENS addresses (but users will have to register their own ENS domains/set their own Cosmos address from app.ens.domains).
2. Add feature to register their own username.keplr.eth or username.keplr.xyz addresses from Keplr (We can pay out of pocket for the initial gas fee for a limited amount of users).
3. Add feature to change Cosmos address for the Keplr subdomains.

[okwme]

@dogemos love it!

[Thunnini]

I committed the initial code to support ENS on the "ens-support" branch. In this build, you can send assets to the recipient by using ENS anyway. But, the main problem is that the fetching process is changed as asynchronous, so it makes the control of the flow to form more difficult. And, this makes the form UI works irregularly. I need the study for react-hooks-form to make it work more appropriate in asynchronous process. But, I guess that it won't take so long.

[Thunnini]

And, in the above phases, I think that phase 1 is possible soon. After fixing the flow of form for ENS, I think it can be released after some QA.

But, for phase2 and 3, I think the paying out on behalf of the user can be done by meta transaction concept. But, the research is needed. And, we need the web UI to permit the normal users to register a subdomain. It seems to be somewhat big work. So, it is not easy to estimate the working period for phase 2 and 3.

@dogemos

[Thunnini]

I merged the ens-support branch into master https://github.com/everett-protocol/keplr-extension/commit/3a86d4a3ddb64f25af8b1aed7c83fa9129a47339. And I think that it can be released soon with just simple QA because Keplr is just beta stage and users know it. @dogemos

[dogemos]

'Phase 1: Transferring ATOMs to registered ENS domains' is complete.

Deployed on Firefox, pending review for Chrome (should be ready in 2-3 days)

[okwme]

YAAA, can't wait to try it : )

[Thunnini]

@okwme @dogemos I researched the way to implement the ENS registration process. It shouldn't require users to install the wallet for Ethereum and to have ETH. At first, I thought that it could be implemented by using the meta transaction concept. But, after some research, I realized that the ownership of the registered ENS subdomain should be not a user but the contract of meta transaction. However, it seemed that there is no general meta transaction implementation that is used widely and is supported by the popular wallet like Metamask. It seems that the meta transaction concept wallets like Argent have their own meta transaction contract and they are responsible to manage these contracts. But, we can't be sure that we will manage our meta transaction contract even though we have the plan to support the Ethereum. And users can't use this meta transaction contract until we support the meta transaction contract generally. So, I gave up using the meta transaction concept. So, the remaining way to implement this is that we send the transaction for subdomain registration on behalf of users if users request the registration. It is not a suitable way to blockchain technology. But, I think it is not a big problem if we provide the choice that we give ownership of subdomain from us to a user. We are prioritizing the address book feature #6. So after implementing the address book feature, I believe that the ENS registration will be implemented in the near future.

[okwme]

This sounds like a good plan @Thunnini . I've had similar problems with the meta-transaction network and came to a similar conclusion. I was however, trying to integrate a metatransaction system on POA at the time which was not supported by the gas station network (https://gsn.openzeppelin.com/). Before getting too far trying to implement your own pipeline I'd just confirm you saw this option and it was also not viable. Otherwise I think you're right that setting up some kind of secure daemon that Kepler operates and can make transactions on behalf of users would be useful.

It could also be interesting to look into a subdomain manager contract that just verifies signatures from cosmos addresses? I'm not sure how difficult it is for example to convert public keys to bech32 encoded addresses within solidity (or if it is necessary), but it might make it possible for kepler users to sign a message ("I want this subdomain" for example) with their cosmos key and that could be the message submitted to the eth contract, verified and then confirmed... This might just be a more complicated version of the system you had in mind already but would be curious to hear your thoughts.

[Thunnini]

@okwme Thank you for your suggestion. GSN from openzeppelin seems to have good potential in the long term. We don’t plan on integrating it immediately, but will consider it when Keplr grows more and GSN matures.

IMHO, one of the best features of bech32 address is that it prevents unintentional action from mistakes such as misspelling. So, I woud prefer not to pass the address to solidity as bech32 format. Perhaps a raw bytes formatted address would be enough of an option for solidity. However, I think the biggest issue with verifying a cosmos standard tx is Amino. If there was a Cosmos standard similar to EIP-712 which can sign and verify arbitrary data, this would be a good approach, but at this time we plan on putting emphasis on fast implemetation--and plan on improving standardization once we see some demand.

[Thunnini]

@okwme @dogemos

https://dev.wallet.keplr.app/#/dashboard

I've deployed the initial test version of the registrar server on ropsten and frontend. It hasn't been tested much, and may contain bugs, but it shows that it can work.

One problem that I encountered was with our need to use the reverse registrar to search for the registered domain. I initially thought we would be able to register the domain with the address and the reverse domain at the same time, but after closer examination, I realized that we have to know the private key of the Ethereum account to register to the reverse registrar (as the reverse registrar only allows the transaction sender to register) (https://github.com/ensdomains/ens/blob/master/contracts/ReverseRegistrar.sol#L50). Since we can't get the private key from the users, we can't register the reverse domain using the 'standard' method.

To solve this problem, I used our parent domain as the reverse registrar. For example, the reverse domain is registered in the following format: HEXADDRESS.keplr.eth (rather than the standard HEXADDRESS.addr.reverse) when registering the domain. Obviously, this may not be the standard way for ENS, but it seems like this may be the only way to get around this problem.

[okwme]

Hey @Thunnini interesting problem with the reverse registrar. I wonder if using the ENS subgraph might circumnavigate the problem. https://thegraph.com/explorer/subgraph/ensdomains/ens Should allow GraphQL queries about all ENS records. I haven't taken a look at exactly what they're indexing and how they're storing it but I imagine it might provide the necessary query to avoid the need for the reverse registrar...

The new interface looks great but I get CORS errors when I try to set a name.

Access to XMLHttpRequest at 'https://ropsten-ens.keplr.app/ens/request' from origin 'https://dev.wallet.keplr.app' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

POST https://ropsten-ens.keplr.app/ens/request net::ERR_FAILED

[Thunnini]

@okwme We're using the t2.micro instance on AWS to run the test server. But, server periodically shuts down due to lack of RAM. 😢