IconResolver proposal

This Proposal adds new resolver IconResolver which adds an icon property to the resolver. This Icon is a multihash addressing to the icon directory. For example it could be an IPFS CID. The directory should contain a set of icons from size 32px to 512px.

Similar icon format is a standard for native apps developers. Such icons could be used as site/dapp favicon or PWA icon, company logo, personal avatar or other identity.

PR

Icon name convention

Grammar:

name
  = "icon_", size, ".png"
  | "icon_", mode, "_", size, ".png"

mode
  = "light" | "dark"

size
  = size-set
  | size-set, "@2x"

size-set
  = "32x32" | "64x64" | "128x128" | "256x256" | "512x512"

Example

Common icon:

icon_32x32.png
...
icon_512x512.png

Light icon example

[email protected]
...
[email protected]

Rationale

I’m developing a browser with native dapps support and it should to resolve app icons somehow. I’d prefer to use a blockchain as a source of this data due to its interoperability.

Note

EIP 928 on Ethereum repo seems to be dead and probably outdated. Decided to move it here.

Can this be done with text records instead, rather than adding a new resolver type?

It seems like EIP 928 proposes wider usage, thus I assume that in some cases resolver could not have text records. For me it looks similar to contenthash property.

Each time we change the resolver interface, users have to upgrade resolver, which requires them to point to the new one AND to reset everything they pushed in the previous resolver. We cannot afford to do that for any piece of metadata a developer wishes to attach to ens names.

That’s why we have generic key value store. Just like an ERC725 profile built in the resolver. I strongly think we should use that instead on adding new interfaces: Simpler interface to the resolver, less resolver upgrade, less blockchain space usage …

I’m not sure what you mean by this - can you elaborate?

If it’s an official position of ENS, then it should be corrected to something less radical, because it looks like refusing of the progress and development. I don’t think that people would stop invent something new for the ENS and there should be better growth strategy.

I’ll try to elaborate. 1. There is already one specific property contenthash which is separated from txt records and it’s understandable to me why it is so, this solution has the same logic is to be separated and to work standalone without TXT records implemented. 2. EIP928 suggests the usage in wallet, dapps, and other software. We need solution which works in the most same way everywhere. And merging it into another weakly typed interface breaks the logic of such interface, I assume.

For contenthash and multicoin support, it supports more than one usage(eg: contenthash supports not only ipfs but multicodec standard ). Your EIP928 only supports one type of profile data type which looks subset of https://eips.ethereum.org/EIPS/eip-634 to me. Can you not extend eip634 ?

I’m not associated to the ENS team, so it’s not an official position. I believe decisions should be not taken by a few one in position of power but by a community. That’s why I give my opinion, and you are free to disagree

That been said, I feel like there is progress and development in value proposition that go beyond the complexity for the sake of complexity.my point of view (again only me) is that what you are proposing is already feasible without changes, and I don’t see the point of adding changes that do not provide any new features. The advantage of having a dedicated entry for icons is, to my opinion, far outweighed by the precedent it creates, that every metadata can and should have a dedicated entry. If we follow that rabbit hole, I’m afraid we will end-up with overly complex resolver, unsustainable standards, and painful update process for the users.

It would be so much easier for everyone if you “just” standardize the key entry (in the text record) used for icons. All resolved address are already compatible. The resolver ABI is known by all apps, and apps that need to work with icons just need to know that key … which is not an issue considering your approach requires them to know the new abi AND implement fallback/upgrade mechanism if the resolver doesn’t implement it

  1. EIP928 isn’t mine. It’s proposed by another developer and was widely supported by community and received good comments from ENS members. That’s why I referred to it.
  2. IPFS is de facto standard for distributed file storage, using other solutions will lead to platform fragmentation. The record could be presented as multihash, but the number of providers should be limited and prescribed in the specification.
  3. Actually missed that avatar already presented in TXT records. I think proposed changes to the file system layout should be included into the specification. Otherwise this field seems incomplete and mostly useless.

Accepted. I still have some concerns about text records not related to this discussion, but the arguments are reasonable. Let’s focus on the icon format and file layout to close that question which is more important as I think but has not been discussed yet.

Changes which should be made:

  1. Make the value a multihash.
  2. Limit/recommend the supported storages.

@nickjohnson, @makoto, @Amxx Does anyone has thoughts, concerns, ideas or, maybe, use cases I missed?

I’m with you on that. There is a usecase for a bytes32=>bytes mapping for storing this kind of metadata (a good complement to the existing text records)

I believe keys should be bytes32 (hash of a descriptive string) and values bytes to support any, key specific, formats (in many cases multihash)