MIP - ENS Support

[tboeckmann]

Simple Summary

Add ENS support so users can send messages using ENS names instead of Ethereum account addresses.

Abstract

ENS abstracts Ethereum account addresses with human readable names, making it more simple to enter an address (forward lookup) or lookup a sender (reverse lookup).

Motivation (*optional)

This improves the UX where an ENS name can be entered instead of an ethereum account address.

Sender addresses can also be resolved through a reverse lookup, making it clearer who sent a message.

Advantages include:

• easier to remember and enter addresses
• less error prone
• easier to understand who sent a message

Specification

The mailchain interface should follow ENS guidelines from ENS Resolving Names

Developer libraries are available but not all node implementations offer ENS support.

Mailchain uses Alchemy and Infura endpoints by default, both already support Web3 ens endpoints.

Without a library

Forward Lookups:

1. Normalise and hash the name - see name processing for details.

2. Call resolver() on the ENS registry, passing in the output of step 1. This returns the address of the resolver responsible for the name.

3. Using the resolver interface, call addr() on the resolver address returned in step 2, passing in the hashed name calculated in step 1.

Reverse Lookups:

1. Get the resolver for 1234....addr.reverse(where 1234... is the address you want to reverse-resolve)

2. and call the name() function on that resolver. Then, perform a forward resolution to verify the record is accurate.

NOTES:

1. ENS is Ethereum specific, therefore only concerns the Ethereum implementation.

2. No caching should be implemented in either direction.

3. See ENS Resolving Names for more information

4. An ENS record should be displayed according to the ENS front-end guidelines.

5. ENS lookup results will be different across different networks (testnets and mainnet).

Rationale

The Mailchain client uses standard Ethereum JSON RPC calls wherever possible to give wider support for different nodes.

Because ENS is not supported on all nodes, the lookup calls will be implemented using web3 and infura's endpoint.

• [x] TBC: in the Mailchain Inbox?

This removes complexity around different node support.

Backwards Compatibility

There is no preceding compatibility to take into account.

Test Cases

• [x] The interface should handle forward lookup of ENS addresses.
• [x] The interface should handle reverse lookup of sender addresses to ENS addresses.
• [x] The interface should handle where no ENS record exists.

Related MIP

N/A

[robdefeo]

It's a valid concern about how to handler ENS lookups for self hosted RPC endpoints, meaning if the node was calling it then it would break without it, this needs to be avoided. Also as mentioned what about other chains that don't have an ENS type function. Whats the flow with forward lookup? Resolve ENS name to address then send to that address? In the scenario what happens if I want to say I am sending from my ENS address e.g. recipient.ens and have the respondent reply to this. Does that mean that the ENS is converted to address at that moment. What happens if someone points their ENS at a different address.

I propose having some sort of address look up facility so ENS address can be resolved - relay to Alchemy and Infura in the case of ENS. Or route to ENS like for other protocols. In addition it could easily support something like recipient@mailchain thats probably another MIP that links to this one.

Questions:

• How would the frontend store creds/config for infura/alchemy? This would still be needed in reverse lookup

[tboeckmann]

Also as mentioned what about other chains that don't have an ENS type function.

Some other chains have equivalent Name Services but should be looked at on a case by case for now until an interoperable name service is standardised.

Whats the flow with forward lookup? Resolve ENS name to address then send to that address?

Idea is to follow the ENS input guidelines, which takes the input and attempts to resolve after a slight pause. The results will be displayed together so user can check the ENS name is the right one and can visually check the address if needed.

Does that mean that the ENS is converted to address at that moment.

Yes. Name Resolution Services should always be a realtime lookup (or within TTL limits like in DNS).

What happens if someone points their ENS at a different address.

Presumably there would be a reason for this change, but not something we really need to be concerned with.

Sender & Forward lookup If you usually send messages to tim.eth (resolving to 0x11...) and I go and change the address to 0x22..., then you would still expect me to receive the message in the same way a DNS request handles websites.

Recipient & Reverse lookup If I send a message from 0x11... that resolves (reverse lookup) to tim.eth, the recipient will see the display in the Inbox as from tim.eth <0x11...>. If I later change tim.eth to resolve to 0x22..., then the message in the Inbox will no longer reverse resolve tim.eth, to the message I sent would be seen as <0x11...> in the Inbox.

I propose having some sort of address look up facility so ENS address can be resolved

Can you use: https://github.com/wealdtech/go-ens ? Or is it easier to simply write the resolver code for the forward and reverse lookup methods?

How would the frontend store creds/config for infura/alchemy? This would still be needed in reverse lookup

For now, xxxx.infura.io without authentication works.