ENS integration

[tschubotz]

see epic #3

[rmeissner]

Do we display both ENS name and address in parallel or just the ENS name if available?

I would actually only display the address ... or the address and the ens name. This is primarily since on the review screen we normally have no information about the ens name.

Best would be if we get the user to add this name to the address book. Maybe we could keep in the address book also a list of ens domains that have been used with this entry (but this is a different topic, with different challenges)

[rmeissner]

For contacts in the address, do we display the contact name or the ENS name?

I would always prefer the contact name. They are local and set by the user, while ens names are pulled from the chain and set by other users

[fairlighteth]

Also just for context, if we'd go with the bottom sheet implementation, you can see this in #43

[fairlighteth]

For contacts in the address, do we display the contact name or the ENS name?

I would always prefer the contact name. They are local and set by the user, while ens names are pulled from the chain and set by other users

Just replying on your previous comment @rmeissner Curious on your reasoning behind preferring the contact name:

From my understanding ENS is exactly how domain names (www/email) work right now. In case of a contact (in the Safe app) we could see that as a local version of that.

Even further we could say a single contact is not just a single address, but could contain multiple addresses (Aliases? ENS's?). But that's out of scope for here.

But to me having a universal (as in ENS..) accepted/registered name is a certain proof that the address is correct, assuming I trust ENS and I received the ENS name from a source/recipient I willingly trust. So in that light I wonder if a contact in the context of our app could contain both the address and ENS name if available? I'd imagine the public address taking precedence over the ENS (lookup if ENS name exists for public address?)

Then a counter point: From a security point of view, is it desirable to only use a ENS name as a point of reference? What if the underlying connected Ethereum address has been modified for the ENS name without the knowing (either malicious or otherwise)?

In that light I then do understand your point to prefer local names:

• You input the contact's address once initially (using ENS or not, doesn't matter, just to pull the public address)
• User then is responsible for using/updating the correct contact's address, which in case public address modifications won't happen without knowledge to the user given we're not relying on ENS.

Also @Mettenim curious on your thoughts.

[rmeissner]

Yeah I was mainly thinking about the last two point mentioned ;)

[Mettenim]

Since ENS is still quite new (and we are not pressed to implement it right away), I would like to approach the development of this feature systematically, with comparative research into how ENS is used by dapps and other wallets, evaluating the effectiveness of their approaches, --and collect information on what users preferences are-- before making assumptions about what would be the best approach. There are a lot of questions that would be quickly clarified by this process.

[posthnikova]

I checked how other apps do this (Argent http://joxi.net/MAjzNMVHjLGBGA, Cipher http://joxi.net/Vm6aMbet4zkWZr, PandaX http://joxi.net/YmEyOkeIwDWoJm, AlphaWallet http://joxi.net/RmzYagOfY5lJ8r, Status http://joxi.net/1A5Zg9eCD1WYGr, imToken http://joxi.net/p27RGLeiKx6dZm).

Open question is how to format the addresses. Argent aims at replacing long addresses with ENS completely. Other apps tend to display ENS and long address in parallel, at least on Send screen. Status doesn't display ENS name on Send screen, only long address.

No one solved the issue with having the address in address book. I couldn't figure how to add a contact in Status. imToken has address book but doesn't let input ENS name while creating new entry.

Here is my proposal:

1) Sending

The user can enter ENS address in the recipients field. When it's already in address book, custom name from address book is displayed alongside ENS name.

2) Assets view, Receive, owner's address

If available, ENS name is displayed on Assets and Receive screens. https://invis.io/FDSC4B626VU#/366732370_-ENS-_AssetView https://invis.io/FDSC4B626VU#/366732389_-ENS-_ReceiveFunds Also everywhere where owner's address is: https://invis.io/FDSC4B626VU#/366733004_-ENS-_Send_Input_-owner_ENS-

3) Address book

The user can enter ENS name when adding an entry to address book.

[rmeissner]

Do we really want to allow to store the ENS address directly in the address book?

I really like ENS as an alternative way to input addresses, but I am not too sure about a too deep integration. I would always trust a local address book more than ENS. I would rather keep it simple than have a complex integration.

[fairlighteth]

@posthnikova Thank you for sharing the clear overview, really neat.

In a perfect world, I would regard an ENS name as an absolute replacement of a full Ethereum address. To make the analogy: Your email address is what I remember and not the server IP it resolves to.

In that perfect world I would abstract away the full address in almost any interaction: Assets overview, sending funds, etc. Except for perhaps the final review screen (before you submit) we could arguably say it's important to show it there for verification purposes.

Ultimately we can only put full trust in ENS if we can absolutely trust that a specific .ETH address will always and indefinitely resolve to a certain Ethereum address. If that is not the case, then this is a security issue.

If we can't or want to fully trust ENS, and treat it solely as a mechanism to 'pull' an Ethereum address, then we should not regard it as an absolute replacement of the full address. In that sense I would rather see it as a 'NAME' replacement (address book).

Scenarios: 1) .ETH ens name replaces the full Ethereum address in all user interactions with the app (except for maybe the review screen). Example:

• Name: Sasha Postnikova
• Address: Postnikova.eth

2) .ETH ens name is used to 'pull' a certain address. Then the .ENS name is used as the address book name and we continue showing the full address. User afterwards can change the name as they want. Example:

• Name: Postnikova.eth
• Address: 0xf3...9481

In both scenarios it's up to the user to verify that either: 1) The ENS name is correct (and resolves to the right Ethereum address) or 2) That the pulled Ethereum address from the ENS name is correct and stored in their Address book.

If we can fully trust ENS I would go with scenario 1.

Otherwise, security wise, I'd use scenario 2 as in that scenario you only have to trust (and check) the resolving ENS Ethereum address once when it's pulled (in scenario 1 you have to trust ENS each time).

The only drawback here is, if I as an user added an address with ENS with scenario 2, and meanwhile the ENS name owner changed their address, I would be under the assumption that I have the correct (ENS) address, while it's 'outdated'. So scenario 2 doesn't allow for automated address 'updates'. Which in my view is one of the core concepts of a 'name service'...

[tschubotz]

@posthnikova Really nice flows, thank you!

We have 4 different cases:

• Just address
• Address + ENS name
• Address + address book entry
• Address + address book entry + ENS name

I think the biggest question is in the last case. We cannot really display all three cases. I actually like Sasha's proposal to have some kind of hierarchy:

• Just address 👉 well display just the address
• Address + ENS name 👉 show both, ENS name is highlighted
• Address + address book entry 👉 both, address book entry name is highlighted
• Address + address book entry + ENS name 👉 Show address book entry name and ENS name. Entry name is highlighted since the user chose it.

Do we really want to allow to store the ENS address directly in the address book? I really like ENS as an alternative way to input addresses, but I am not too sure about a too deep integration. I would always trust a local address book more than ENS. I would rather keep it simple than have a complex integration.

@rmeissner I'm not sure I understand what you mean. There is an address input field, right? So we should allow ENS input, I think.

[rmeissner]

So my primary issue is, that ENS is a central registry where the domain holder can change how an entry is resolved (e.g. for tobias.argent.xyz, argent as the owner of argent.xyz could change how the entry is resolved and therefore could change the address). Even so this is unlikely, but it is something to consider.

Therefore I would like to make a clear visual difference between ENS entries and address book entries.

Also for an entry in the address book I needs to be clear what we store. Do we store the address, so in case that the ens entry changes you would not see it in our UI anymore and instead the address would be displayed (according to the flow chart). Or do we store the ens url and if the entry changes the blockies would change (since the underlying address changed).

Also I would probably not display all 3 at once (last case), in this case I would propose that we don't display the address and that the tooltip can be triggered when you tap the ens address.

EDIT: I also really like the flow chart :smile:

[DmitryBespalov]

@biocom

Ultimately we can only put full trust in ENS if we can absolutely trust that a specific .ETH address will always and indefinitely resolve to a certain Ethereum address. If that is not the case, then this is a security issue.

To my understanding, the 'indefinitely resolve' is not what ENS is - underlying address can change, and the ENS entry can have a specific time to live after which it expires. The owner of the domain has the power to change it and all subdomains.

@posthnikova Because to enter an ENS name user must type in the address, I propose to remove the intermediate action sheet, and just make the entering the recipient quicker.

Let me explain.

I think that the way standard iMessage app and Mail app do the address entry is one possible way to approach it and use it as an inspiration.

The problem when using your phone is that typing is hard, therefore we must provide all possible options to save effort while typing the address.

At first, when a user taps on the Address field, the keyboard opens with 2 custom bars on top of the ​keyboard - the first bar will have the buttons for quick "paste", "scan", "address book", and the second bar can have recent and most used recipients shown already.

Thus, I would start the flow from the "(ENS) Send_Input (typing ENS)" right away, and not from "(ENS) Send_Input (enter address)" screen on the flow diagram.

When user starts typing in text, then the app starts searching several options: 1) find matching text in address book by name or any associated field (address) 2) if the name looks like a domain, try to resolve it [this can make time, so I think it will need the activity indicator...]

This is how iMessage displays the found results:

Here is how it looks when searching for a phone number

After user selects the intended recipient - we display the address the way we want it. In case of iMessage, it displays just the name, without phone number or email:

Finally, here is a similar solution by the Mail app

[fairlighteth]

@DmitryBespalov

To my understanding, the 'indefinitely resolve' is not what ENS is - underlying address can change, and the ENS entry can have a specific time to live after which it expires. The owner of the domain has the power to change it and all subdomains.

Sorry, I wrote it in a confusing way, but essentially that's what I meant to say: You trust that the ENS address will always resolve to a (correct) Ethereum address, which may or may not change it's resolving address (up to address owner's discretion or expiration).

Thus, I would start the flow from the "(ENS) Send_Input (typing ENS)" right away, and not from "(ENS) Send_Input (enter address)" screen on the flow diagram.

I agree that it can be helpful to 'enhance' the keyboard input with options like 'recent contacts' when you specifically chose the 'Address book' option. I disagree with jumping right into the manual input/keyboard screen (if I understood you correctly) for these reasons:

• The bottom sheet provides clear input options, giving the user a clear overview of available input methods and declutters the initial 'Recipient's Address ⋅⋅⋅' field and the whole Send view.
• By tapping on for example 'ENS' we could show a 2nd level view (Like Status.im) with a specific field for typing in an ENS address, which specifically does validation to detect correct addresses. Then we could also display a correct Ethereum address was retrieved from the ENS address, providing double confirmation for the user. Example from Sasha's screenshot of Argent: http://joxi.net/MAjzNMVHjLGBGA (Address found)

In my opinion that provides for a clear directional flow, where each address input option is best served.

[posthnikova]

Therefore I would like to make a clear visual difference between ENS entries and address book entries.

@rmeissner That creates some questions. Let's imagine we have a special status for "ENS entries" in address book. That means when creating new entry, we should ask the user which type of entry they want to create, ENS or regular entry. Does that mean you won't be able to enter ENS names for regular address book entries? Also will you be able to set custom name for ENS entries?

Also for an entry in the address book I needs to be clear what we store.

ENS names are used to pull addresses and not the other way round so I think we store ENS names. The question is what happens when ENS name expires, changes owner or is resolved to a different address. On the one hand, this is possible to update this automatically. On the other hand, address books aren't expected to behave this way, this is a space controlled by the user. Items becoming outdated is a problem of any address book, because people change their phones, bank accounts, credit cards get expired etc. Just storing outdated entries doesn't result in mistakes. Sending to outdated entries does. So I wouldn't change entries in address book automatically. I would perform check when viewing/editing entry and sending to someone from address book and warn if their ENS name has changes.

Because to enter an ENS name user must type in the address, I propose to remove the intermediate action sheet, and just make the entering the recipient quicker.

the first bar will have the buttons for quick "paste", "scan", "address book"

@DmitryBespalov I think this is optimising for those who want to specifically type ENS. For those who use other input methods finding the right option would be less obvious. Actions from action sheet would be moved to keyboard and represented as icons which require some learning. So it depends on how often people would want to type ENS.

the second bar can have recent and most used recipients shown already

Maybe put text labels here ("paste", "scan", "address book")?

I think that the way standard iMessage app and Mail app do the address entry is one possible way to approach it and use it as an inspiration.

I like that entering address is on separate screen, we could do all validation there. I also like that there is visual distinction between different types of entries while searching, we could use it. I'm not sure if we should use this approach now, because: • ENS is new and people would paste addresses more often than type • This is optimised for choosing from large list of contacts and sending to several recipients. Also this is for accessing recents and any e-mail addresses/phone numbers you've ever had interaction with, regardless of contacts list. I don't think this is our case.

[rmeissner]

@posthnikova I would not allow to store ens urls in the address book. I would only store addresses. So you can use ens to get an address that you want to store in the address book, but I would not store the ens address itself.

ENS names are used to pull addresses and not the other way round

yes, the main use case is to pull addresses, but the other way around is possible with ens and might actually be more interesting (also more risky for the user, since this allows spoofing)

[fairlighteth]

@posthnikova @rmeissner To Sasha's point: Outdated information in any address book, generally is something you'd have to update yourself. I think ENS has the perfect opportunity to solve just that.

But to make the comparison with the way e-mail addresses work: Why would I want to care about the resolving address if I just got the correct e-mail address? I always assume that the e-mail address I'm sending something to both exists and resolves to whatever mail-server the recipient has setup behind it.

Of course with ENS there's a security aspect we need to keep in mind. I like the idea Sasha coined, to perform a check each time, to alert the user if the resolving Ethereum address changed of a .ETH address. This would allow best of both worlds:

1. I store/send funds to an .ETH address I checked/approved upfront (by also viewing the full 0x.. address).
2. Whenever the resolving address changes I need to re-approve, so that I'm aware that funds will be sent to a new (resolving) address (while the .ETH address cosmetically remains the same). If approved, the new resolving 0x address is updated in my address book for the corresponding ENS. If I reject it remains the same. But arguably the use case here is protecting the user from all sorts of attack vectors/spoofing.

[DmitryBespalov]

I think that storing ENS and notifying the user when the address is changed has more value for the user than not storing ENS addresses.

By the way, there could be multiple ENS / addresses for the same address book contact, right?

[rmeissner]

I think we are making the address book/ ens unnecessary complex

I would love to understand how much value stored ens urls have compared to just stored addresses.

Also personally I would like to limit the integration of ENS to an alternative input (on the same level as "paste from clipboard") since there are quite some cases that are in my opinion are not secure (since they basically introduce most of the attack vectors that DNS has)

I might overestimate the security issues and the complexity, still I see the major value of the address book in storing a label to a single address. This is the least time consuming to implement compared to the additional features of ENS and multiple addresses per contact.

EDIT: In general I think the mentioned features are cool and do improve UX, but for me this is a question of "how much time do we want to invest right now"

[tschubotz]

Meetings notes (Sasha, Michel, Kristina, Richard, Dima, Tobi)

• ENS lookup ("resolve and ENS name): Get the ETH address connected to an ENS. There can be multiple ENS names pointing to the same address.
• ENS reverse lookup ("reverse-resolve"): Get the ENS name stored for a single ETH address. There can only be 1 ENS name stored for a single ETH address.

(1) What do we store in the address book? ENS name and Eth address OR just the address

• We store the entry name + address, NOT an ENS name
• ENS name can be reverse-resolved, i.e. get the ENS name from the address.
• ENS name can be used to input the address.

(2) When selecting a recipient, and there is an address book entry AND an ENS name, what and how do we display it?

• If a user scans/pastes an address and it is not in the address book and there is no ENS name 👉 Just display address.
• If a user scans/pastes an address and it is in the address book 👉 Display address book name and address (no matter if there is an ENS name.
• If a user scans/pastes an address and it is not in the address book and there is an ENS name 👉 Display ENS name and address. Priority on address?
• if a user selects an address from the address book. 👉 Display address book name and address (no matter if there is an ENS name.
• If a user enters an ENS name and the address is not in the address book 👉 Display ENS name and address. Priority on address?
• If a user enters an ENS name and the address is also in the address book 👉 Display address book name and address (no matter if there is an ENS name.

(3) In case we store ENS name, what do we do if the ETH address changes that it points to.

• We don't, so question does not apply anymore.

Should we separate input and displaying, feature-wise? Open question: Do we reverse-resolve? i.e display ENS names

[tschubotz]

@posthnikova @biocom @rmeissner @DmitryBespalov

In order to resolve the still open question, I created this doc with the different ideas and pros and cons: https://docs.google.com/document/d/1UTqBIpyHlWVFk-iY3uQ4dDcu-gvSigki0FOilJCD_r0/edit#

Please review and add your comments / opinions. I moved it to Gdoc since I think it's easier to have different discussion threads and comment on everyone's opinion. Please add your vote on the bottom of the doc and reason about the why.

If we cannot come to an agreement, I will schedule a follow up meeting.

[tschubotz]

I just checked out Argent. They have the exact same issue. I added screens to the gdoc above ☝️

[tschubotz]

Looking the gdoc, seems like everyone is in favor of using ENS to also reverse-resolve name :)

(Taken from Sasha's comment on the doc) I'm for № 2. The only major drawback I see is that one input method creates different results in different places. If you enter ENS on Send screen, you get this http://joxi.net/E2pe0k5U7xBRDA (address is not in the address book). If you enter ENS in address book, ENS disappears because we don't store it http://joxi.net/eAOeJ4aU9D416m. Also when you paste/scan regular address while sending, it resolves http://joxi.net/MAjzNMVHjov65A while in address book it doesn't resolve http://joxi.net/VrwYLQaf7kKpV2

I agree, that we should try to keep it consistent in all the places.

@posthnikova What do you think about using your original idea (https://projects.invisionapp.com/share/FDSC4B626VU#/screens/366731729) And this kind of way everywhere, including the address book entry screens? I would still love to add some indicator if this name is now from ENS or from the address book, but I think this could work. What do you think?

[fairlighteth]

Also worth noting: Argent (as Tobias pointed out) has already implemented it, Status.im is busy with it. Might be worth it to compare options in terms of 'standards' and potential learnings. If interested I can dig more into it.

[posthnikova]

What do you think about using your original idea (https://projects.invisionapp.com/share/FDSC4B626VU#/screens/366731729) And this kind of way everywhere, including the address book entry screens?

@tschubotz In address book, ENS disappears after you save entry, so no, this makes no sense. Address should be primary (in case there is no address book entry), custom name should be primary when there is address book entry.

I would still love to add some indicator if this name is now from ENS or from the address book

I can add some icon or logo itself (http://joxi.net/823LJjeU93K3RA or http://joxi.net/zANeN5ZUvyxVJ2). For those who don't know what ENS is that would not clear things up. Maybe an educational feature would work. For example, when the user makes a transaction for the first time and ENS name is found, we could add an intermediate educational screen (What is ENS? Why am I seeing this?). If the user specifically chose to input ENS name, I guess education is not needed.

[tschubotz]

@tschubotz In address book, ENS disappears after you save entry, so no, this makes no sense. Address should be primary (in case there is no address book entry), custom name should be primary when there is address book entry.

Does it have to disappear though? Couldn't we just convert it into something like this upon saving?

[posthnikova]

Does it have to disappear though? Couldn't we just convert it into something like this upon saving?

@tschubotz Isn't it against what we decided at the meeting? To not store ENS names?

(1) What do we store in the address book? ENS name and Eth address OR just the address We store the entry name + address, NOT an ENS name ENS name can be reverse-resolved, i.e. get the ENS name from the address. ENS name can be used to input the address.

[tschubotz]

@tschubotz Isn't it against what we decided at the meeting? To not store ENS names?

No, I would always reverse-resolve the name from the address when someone accesses an address book entry, i.e. we really only store the address. Do you know what I mean?

I agree that this might a problem since users then possibly expect that the ENS name is stored, not the address. But I would live with that drawback and still think that's the better idea.

[posthnikova]

As discussed, we don't store ENS names but display them wherever possible. Check is performed every time address book entry is accessed. I introduced new things: • Badge for address book entries while sending. This helps understand the difference between ENS names and address book names.

• Arrows showing which resolves to what. Ethereum address resolves to ENS or ENS reverse-resolves to Ethereum address.

• Tooltip appears when ENS name is found or while accessing address book entry we detect that ENS is changed.

1) Send (enter ENS name)

https://www.dropbox.com/s/lowe761z07mgo8d/Send_input_ENS.png?dl=0 (not uploading here because of size limitations)

2) Send (from address book)

3) Send (paste and scan)

https://www.dropbox.com/s/sbs8gok7z9bzq0x/Send_paste_scan.png?dl=0

4) Owner's ENS name

5) Address book

https://www.dropbox.com/s/uly0e2eavtn29qv/Address_book.png?dl=0

[fairlighteth]

Thank you for the updates Sasha. Some comments my side:

• -> I would add a white border around the icon so the badge stands out from the identicon. Similar the way we do that in the transaction list.
• The arrows to indicate what resolves to what, makes sense when you explained it to me. I have serious doubts that a non-informed user would understand the flow, merely from looking at the arrows. The question is: What benefit does the user have in knowing the direction/flow in terms of resolving? Could the user still use and understand the app and the address/contact functionality without it? Currently I'd be inclined to say, the arrows add no value. Let's discuss.
• Error: The ENS domain hasn't been mapped to a proper address: In terms of helping the user to understand and allow to 'fix' the error, I would point out that the ENS domain simply doesn't exist or 'to make sure the ENS domain exists'. Saying 'hasn't been mapped to a proper address' is quite the long/technical explanation. This assuming that existing/activated ENS domains always require a valid 0x address to resolve to (I guess that's a requirement for setting up ENS).
• As for the places where we show ENS addresses: How do we handle long ENS addresses? Do we trim? Do we wrap?

[rmeissner]

Yeah I also really like the flow diagrams and the look of the address field.

I have a couple (subjective) notes:

• Not sure if the person icon for the address book on the identicon might be confusing in some cases (e.g when the dutchx contract is in the address book) ... but maybe this can be ignored
• personally I am not a fan of displaying the address below the input field ... don't we have the tooltip that appears to display full addresses?
• I would like to be clear if we want to detect changes to ens entries (because in this case we need to store them locally)
• While I like the arrows, I do agree with Michel that this might not be understood by all users. (Also this adds quite some complexity where we should check if it has the corresponding benefits)
• While these flows mainly focus on the display of the ens addresses, I would like to mention that I prefer the ens input proposed by @DmitryBespalov (this would have an impact how ens is display in the send funds screen)

[tschubotz]

Thanks very much for these thorough flow diagrams. This helps a lot!

• When making transactions, the arrows could be misleading since they look as if they depict the flow of funds.
• I think it is not ideal to let users enter ENS names directly in the input field since this would require us to do all validation on this screen. Also, users might be confused that they cannot enter addresses in this mode.
• I think it might be worth already converting the address to the ENS/address book name on the start screen of the "Send funds" flow.
• I like that address book entries are marked with the small contacts icon!
• I'm still in favor of displaying the address always in the 2nd line, if there is an ENS name or address book name. If ENS+address book entry exist, ENS is ommited.

[posthnikova]

I would add a white border around the icon so the badge stands out from the identicon

@biocom Agree

What benefit does the user have in knowing the direction/flow in terms of resolving

This is for the cases when ENS name pops up when it's not expected. Other wallets don't use reverse-resolving so far, so it's a new functionality. Arrows are here to inform that both directions are possible.

Could the user still use and understand the app and the address/contact functionality without it?

While I like the arrows, I do agree with Michel that this might not be understood by all users.

When making transactions, the arrows could be misleading since they look as if they depict the flow of funds.

@biocom @rmeissner @tschubotz There are arguments against arrows but I would still like to do user tests with the most complex version with arrows. We can always simplify later.

Saying 'hasn't been mapped to a proper address' is quite the long/technical explanation

Agree

How do we handle long ENS addresses? Do we trim? Do we wrap?

Long ENS names should be truncated. Full ENS name should be shown in tooltip along with full address (ideally, only in cases when address is truncated to avoid duplication).

I would like to be clear if we want to detect changes to ens entries (because in this case we need to store them locally)

@rmeissner When storing and viewing entry changes are not detected. Sending to entry from address book and editing entry need detecting changes to ENS. Appearance of past transactions in tx list and tx details doesn't need to change.

personally I am not a fan of displaying the address below the input field

I agree, full address goes to tooltip.

I think it is not ideal to let users enter ENS names directly in the input field

@tschubotz There are system popups with input field on iOS but they are for passwords. http://joxi.net/YmEyOkeIwjGGWm http://joxi.net/v29OEJeSZO446r Unless we want to do custom popup I would do validation on a separate screen. Choose input method -> go to separate screen -> input, paste or scan, tap Done -> validation is performed -> return to Send screen. We'll have to change this everywhere address is entered (address book).

I think it might be worth already converting the address to the ENS/address book name on the start screen of the "Send funds" flow.

On iOS tapping "Go" or anywhere outside the keyboard closes keyboard and starts validation http://joxi.net/DmBJaEeHJjq8Dm. Not sure if that's what you mean.

I'm still in favor of displaying the address always in the 2nd line

That means, when you're adding a new entry to the address book, you use ENS name as an input method but then ENS disappears and entry is displayed without ENS. And the case when ENS name is found for address book entry is no longer applicable http://joxi.net/L21W8jehRWwZQr.

[posthnikova]

Changes after user tests. What's been done:

1) Removed small arrows because they didn't perform well

2) No longer reverse resolve after pasting full address or scanning QR code (while sending and creating/editing entries in address book)

3) Still reverse resolve in three cases when there is a risk that ENS name has changed: • In Tx details, when the address is in address book and ENS had been used to send funds. After tapping "Send again" perform check «address -> ENS». If some time passed and corresponding ENS changed, display new ENS • While sending, after the user chooses entry from address book for which ENS name is displayed, perform check «address -> ENS». If ENS changed, update it on Send screen and in address book. • In address book, when viewing entry for which ENS name is displayed, perform check «address -> ENS». If ENS changed, update it in address book.

4) On Receive screen: removed arrow, added copying ENS name separately. Tapping on address only copies address

5) Tx details: removed arrows

6) ENS input is now on separate screens because it's hard to make our existing recipients field editable. The user types in ENS name, check is performed immediately. As soon as there is proper format in the field, ENS is resolved into full address, the user taps Confirm and returns to Send_input screen. Back also returns to Send_input. The same in Address book.

7) Send input: make clickable zone around three dots bigger

8) Address book: added arrows to entries in the list to make them look clickable. Added green badges to identicons in the list.

9) Changed order of items in action sheet (from more popular to less popular)

The flows:

• Send (with ENS name):

https://www.dropbox.com/s/us226szz55weiwy/Send.gif?dl=0

• Send (from address book)

• Send (paste & scan)

• Owner's ENS name

• Address book

To do: Add tips on how to start transaction to onboarding slides

[KristinaMayman]

The changes look good to me! Of course, I made some assumptions about how to fix the issues that came up during the user tests, but I think these adjustments will help.

[lukasschor]

It feels like we could reduce a lot of complexity of the ENS feature by not allowing to save ENS names in an address book entry.

Could we maybe reduce a bit of the weight of the feature and by still allowing to input the ENS name in the address book entry but by only storing the actual address?

As a result in the send / transaction view we would either have an address book entry or ENS name that resolve to an address, but no address book entry that resolves to ab ENS name.

This means that ENS would always only be used to immediately resolve to the associated address which also increases security regarding the underlying address changing. (only exception being the reverse-lookup of the owner own Safe address)

[rmeissner]

@lukasschor the behavior you describe, is how I was understanding it from the beginning

[tschubotz]

Thanks a lot for updating the screens and flows! Here are my thoughts:

(1) What did you have in mind for "invalid address"? I think only the following 2 error cases exist:

• ENS name doesn't exist.
• ENS name exists, but no address is set. I would say the user should in both cases see "No address found". What do you think? Also, an ENS address is not always asdf.eth I just remembered. tobias.argent.xyz would be valid too, e.g. .eth will be most popular though.

(2) I like the receive screen, also that the user can copy their ens name.

(3) I like that ENS addresses get a separate screen where they can get entered.

(4)

No longer reverse resolve after pasting full address or scanning QR code (while sending and creating/editing entries in address book)

Still reverse resolve in three cases when there is a risk that ENS name has changed: • In Tx details,

That means we need to remember on the client if ENS had been used. I feel like this is not possible. The transaction list in the backend would also need to know about this.

That would now mean, we would reverse-resolve in some cases and not in others. I'm a bit hesitant about this solution since this would require us to store even more info about a transaction which I would like to prevent.

[rmeissner]

For (2) where is this ens name coming from?

[lukasschor]

UX Sync Decision:

• Only allow input for the ​first version
• Reverse Resolve on Receive Screen

[posthnikova]

In the new version ENS is only used for input. After an address is found, ENS disappears.

ENS is typed on a separate screen: https://invis.io/FDSC4B626VU#/376688215_03_-ENS-_Send_Input_-typing_ENS-. Check for an address is performed while the user types. After proper ENS format was recognised, a tooltip appears with an address and "Confirm" button becomes active. Check is also performed on tapping "Go" on keyboard or tapping anywhere outside the keyboard. You can dismiss the tooltip by tapping on it and type another ENS name. After tapping Confirm the address is inserted into recipients field and ENS disappears.

Send: https://www.dropbox.com/s/6h3jot0yb4t43mo/2019-07-31_Send.gif?dl=0

Owner's ENS name:

For (2) where is this ens name coming from?

@rmeissner It comes from reverse resolving. Is it possible to check for owner's ENS name frequently (ideally every time the app launches)?

Address book:

[lukasschor]

I like the simplicity of this implementation. Two comments:

1) ENS names do not necessarily need to end in ".eth", they can currently also end in ".xyz" or ".luxe" and a lot more TLDs in the future. Maybe in the validation error state, we should just say "Address is invalid" in all cases where the input does not map to a valid ENS name. (Still keep the error where the ENS exists but does not map to a proper Ethereum address)

2) For reverse resolving the owner's​ address, should we only show the reverse resolved ENS name in the receive screen? If yes I would just pull the mapping every time receive screen is opened.

Let's discuss in the UX Sync.

[lukasschor]

1) UX Sync: Yes, and delay validation 2) UX Sync: Only reverse resolve on receive screen

[lukasschor]

UX Sync: Explaining that valid address was found & Android Screens

[posthnikova]

New version and android are up for review: https://invis.io/FDSC4B626VU, https://invis.io/X9TA720FC8Q.

1) "Wrong format" error removed

2) Owner's ENS name is on Receive screen only

3) "Address found" message is more prominent: https://invis.io/X9TA720FC8Q#/377146093_-ENS-_Send_Input_-ENS_Filled_-_Address_Found-_, https://invis.io/FDSC4B626VU#/376688220_08_-ENS-_Send_Input_-ENS_Filled_-_Tooltip-. Check for address is performed as the user types, the message is shown with a delay when the user types a properly formatted ENS name.

[lukasschor]

I really like the new „address found“ message. 🙌

[KristinaMayman]

Agree, I think it works well!

[DmitryBespalov]

I see progress, good job simplifying it 👏

One comment to @posthnikova is on the ENS input screen, the tooltip is shown as the ENS is typed in. How exactly is that working?

[posthnikova]

@DmitryBespalov Tooltip was discarded, now it's a message under input field. Ideally it should show immediately after the app finds a corresponding ethereum address, or after the user stops typing, or on pressing Go on keyboard, or on removing focus from field. If format is incorrect, or address wasn't found, errors show after the user stops typing, or on pressing Go on keyboard, or on removing focus from field.

https://projects.invisionapp.com/share/FDSC4B626VU#/screens/376688220_08_-ENS-_Send_Input_-ENS_Filled_-_Tooltip-

[DmitryBespalov]

ok

[tschubotz]

Are there still open questions on this one? If not, could you please upload the screens to zeplin when you get the chance @posthnikova ? :) Then I would go ahead and finalize the spec ticket for development.