Token's icon standard - AEIP15

[samuelmanzanera]

This is a discussion for the AEIP15 located at: https://github.com/archethic-foundation/aeip/blob/main/AEIP-15.md

[samuelmanzanera]

In the AEIP you described external links for the icon, but we should probably support base64, aeweb links as well

[redDwarf03]

ok you advice to reuse the content's NFT structure :

"icon": [
    {
      "content": {
        "raw": "BASE64 of the image"
      },
     "scale": "1x",
      "size": "16x16"
    },
    {
      "content": {
        "aeweb": "0000f2c75f55fb398e99b6a5e674c3422731fb167f79b9b08131dcfa3bb830d50b9a/image.png"
      },
     "scale": "3x",
      "size": "64x64"
    }
  ]

raw (string): The base64 encoding of the NFT content.
ipfs (string): The IPFS URI to the NFT content (e.g., ipfs://bafybeihkoviema7g3gxyt6la7vd5ho32ictqbilu3wnlo3rs7ewhnp7lly/).
http (string): The HTTPS URI to the NFT content (e.g., https://my-website.com/image.png).
aeweb (string): The Aeweb reference address and path to the file for the NFT content (e.g., 0000f2c75f55fb398e99b6a5e674c3422731fb167f79b9b08131dcfa3bb830d50b9a/image.png).

is it ok for you @samuelmanzanera ?

[Neylix]

A thing to consider is that the icon of a token can evolve over time. So I'm not sure if allowing to use static data like raw or ipfs is a good idea. This means that the icon of a token is forever.

Other thing to think about is that this new field should be integrated into the token id calculation. As a token with same property but with a different icon is not the same token I think

Also I think about AEFS that will replace AEWeb. In near future AEWeb will be designed and used only for website hosting and not anymore for static content. So I don't know if putting AEWeb there is a good idea for now as it will be replaced by AEFS in this case

[Neylix]

Few remarks:

• I think this AEIP does not require AEIP-9 since AEIP-9 is designed for non-fungible token while your AEIP is for any kind of token. Also we can have an NFT with an icon but without specific image or external content.
• I would also mention that there is a risk for end user to have the icon directly in token specification. Anyone could create a random token and use an icon of a mainstream and well known token (Bitcoin for example). If the application that fetch the token specification (i.e wallet) blindly trust the token icon, the token will be displayed with the BTC icon while it's not an BTC. This may fool the user of which token is a real one.
  So to avoid this confusion, the application needs to ensure before displaying the icon that it is the good one, but in this case there is no need to to have the icon in the specification if all application filter it.
  Actually on other blockchain, there is some trusted service like coingecko or coinmarketcap that expose a list of known token with their icons. We could have a similar approach, or maybe create a on-chain list of trusted token with their icons.

[redDwarf03]

it's the same pb if someone create a token named "Bitcoin" with a "BTC" symbol no ? no just a icon pb...
I agree with a trusted service who exposes the Archethic address of known tokens with the def of the token (name, symbol, icon) but not agree with your argument of positionning icon outside the def of the token

[Neylix]

I feel like token specification is not the right place define icons.
The main goal of a token is to create an entity that a user will own. For a fungible token, in fact you just own a token id, for non-fungible token, you own the token id plus the properties of this token.

But do the user need to own the icon of a token ?
We can have the same question about the name and the symbol, the user don't need to own them.

In AEIP-2 we took inspiration from the current usage of tokens where name and symbol are always used by front end applications.
For convenience the icons could also be part of it, I agree.

So I think it could be interesting for friendly usage to have the icon in the specification as well as the name and symbol, but not all the icon definition using scale and size. As you said in other comment there is multiple scale and size possible, and the token specification is not made for having 25 variations of its icon.

What I propose is to have a simple attribute icon with a link or something else but all the icon variant are defined behind this link.

For example :

{
  "supply": 200000000,
  "type": "non-fungible",
  "name": "My collection",
  "symbol": "NFT",
  "icon": "https://my-website/icons",
  "aeip": [2, 8, 15],
  "properties": {}
}

After the url "https://my-website/icons" we can define a behavior to find the rigth icon size like "https://my-website/icons?scale=x3&size=32x32"

We could also have an other functionnality using AENS for example that can store the token_id and redirect to a AEFS storage folder containing the different icons.

[bchamagne]

I am wondering about the size "flexibility". Since the user can set anything, maybe someone will put "20x20" someone else "23x23" someone else "18x18". How do I, as a application developer, deal with this? Isn't it easier to have an enum ["small", "large", "retina"] or something?

[redDwarf03]

The use of idiom is not sufficient.

There are standard icon sizes commonly used in the design and development industry. Here are some of the most prevalent standards:

ICO (Windows Icon): The ICO format is primarily used on Windows operating systems. Common icon sizes include 16x16, 32x32, 48x48, 128x128, and 256x256 pixels.

PNG (Portable Network Graphics): The PNG format is widely used on the web and supports transparency. Common sizes for PNG icons can range from 16x16 to 512x512 pixels.

SVG (Scalable Vector Graphics): The SVG format is based on vectors, which means icons can be resized without loss of quality. It is commonly used for icons that need to adapt to different screen sizes.

iOS: On iOS devices (iPhone, iPad), application icons should be provided in multiple sizes, ranging from 29x29 pixels to 1024x1024 pixels. The most commonly used sizes are 60x60, 120x120, and 180x180 pixels.

Android: Application icons for Android devices can also vary in size. Recommended sizes include 48x48, 72x72, 96x96, and 512x512 pixels. Additionally, Android uses the concept of screen densities (ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi), which means different versions of icons may be needed for different densities.