v1 Display human readable names for "Known" addresses

[tschubotz]

What is this feature about? (1 sentence)

This feature will display human readable when interacting with known contracts/protocols such as Uniswap or Compound.

Why is it needed? What is the value? For whom do we build it?

• The top problem area that we identified is, that users don't know what they are signing and which protocols they are interacting with.
• A first step in getting rid of cryptic addresses is displaying human readable names for known contracts.

High-level overview of the feature

• See mobile spec doc: https://docs.google.com/document/d/1kY7KQ0x135z4TzUsqjAdQ-7z42oKe7-pY89BfOkHkfE/edit#heading=h.cy2pruljhohh
• See Design decisions doc: https://docs.google.com/document/d/12ytKniMH1BpAn8Xqz2QOos2HhnY-JyH8MFA2N2R1d-Q/edit#
  • Local address book names should overrule the human readable name that comes from the backend.
• There is a list or mapping from addresses to human readable names.
  • Multiple addresses could map to the same human readable name.
  • The backend has this mapping stored.
  • Long term, this list could be an onchain registry curated by Safe governance, but that's for later.
  • Example list: https://docs.google.com/spreadsheets/d/1JVvwTfp3WNQ1CXMx8xVQ2n7Aj-u0KDiXxGHNW5OjHb4/edit#gid=0
• The mobile apps already implemented this in the same fashion (v1 Display human readable names for "Known" addresses safe#337)
• The protocol/dapp name (and logo perhaps) should be displayed on the tx list.
  • cf. How Safe app txs are displayed in Uniform transaction list view (Transaction List v2) #820
• On the tx details, the dapp name would also be visible instead of just contract/recipient addresses
  • There should be still a way for users to examine the actual address somehow.

Not in this version

• Known addresses in Settings and in Safe creation tx. This is part of v2: v2 Display human readable names for "Known" addresses #1866
• Known addresses in addresses in decoded data. This is part of v3: v3 Display human readable names for "Known" addresses #1867

Misc

• Related client gateway issue: Return names of known addresses safe-client-gateway#198
• "press release": https://docs.google.com/document/d/11ABA0Nj9gQ_yyCTn-4vgNfJ5XqqputXENTNUcIe03E8/edit
• v2: v2 Display human readable names for "Known" addresses #1866
• v3: v3 Display human readable names for "Known" addresses #1867

[francovenica]

I don't have access to the example list mentioned in the description.
Liliya shared with me this doc with some snapshots
https://docs.google.com/document/d/12ytKniMH1BpAn8Xqz2QOos2HhnY-JyH8MFA2N2R1d-Q/edit#

[tschubotz]

@francovenica I granted access to you and everyone else. Also I updated the ticket description with all info docs we had more mobile with tech specs and design decisions.

cc @nicosampler

Let me know if this is sufficient so far or if we should do a session on the details of this ticket!

[nicosampler]

I suggest we implement this feature in safe-react-components.

We already have the EthHashInfo component: https://safe-components.dev.gnosisdev.com/?path=/docs/ethereum-eth-hash-info--address that provides the Identicon, the address, and the action buttons.

As this feature is required by safe-react but can be also useful for safe-react-apps I think it's a good idea to fetch the gateway in this component and render the known address if there is a match directly in this component.

As a plus, in safe-react and all the safe-apps making use of this component will get this feature by only updating the safe-react-components version.

I would like to hear your opinions @dasanra @rmeissner @mikheevm

[nicosampler]

This task will have two parts:

• Edit EthHashInfo in SRC to support a custom icon.
• In tx-list, when the CW returns to info or if the addressBook has info about it, it will be shown.