chain-registry
chain-registry copied to clipboard
cosmos
Allow for image variants?
For wherever the Chain Registry allows for defining images, we just have a simple 'logo_URIs' object with a png and svg field.
We may want to consider generalizing the name to 'images' instead of logo_URIs? Are there any other useful file types than png and svg? ...perhaps it's best to restrict it to png and svg Most chains seems to have multiple variants of their token logo, due to different themes and changes over time. Here are some properties I think could be used. E.g.,
- Shape. Some dapps might allow for square token logos, while other might insist on circular logos (and might crop a square logo, which can look bad). If there is only a circular logo, and no variants based on share, then simply omit the shape field. Could also eventually allow '3d', which perhaps could be animated on a UI.
- Mode. There can be light and dark mode variants. This can greatly improve UX for adapting to a dark mode.
- Color.
- Background (color).
- Themes. Might want to allow for themes on a dApp, like 'red', or 'Christmas', or 'pixelated', or 'old' vs 'new'.
Image object:
"images": [
{
"shape": "circle",
"mode": "light",
"color": "red",
"background": "white",
"themes": ["red"],
"png": "http://token_logo_circle.png",
"svg": "http://token_logo_circle.svg"
},
{
"shape": "square",
"mode": "light",
"color": "red",
"background": "white",
"themes": ["red"],
"png": "http://token_logo.png",
"svg": "http://token_logo.svg"
},
{
"shape": "circle",
"mode": "dark",
"color": "red",
"background": "black",
"themes": ["red"],
"png": "http://token_logo_circle_dark.png",
"svg": "http://token_logo_circle_dark.svg"
},
{
"shape": "square",
"mode": "dark",
"color": "red",
"background": "black",
"themes": ["red"],
"png": "http://token_logo_dark.png",
"svg": "http://token_logo_dark.svg"
}
]
Alternatively, if the properties feel too much like overkill, there could still be use in just allowing for non-default variants:
"images": [
{
"png": "http://token_logo_circle.png",
"svg": "http://token_logo_circle.svg"
},
{
"png": "http://token_logo.png",
"svg": "http://token_logo.svg"
},
{
"png": "http://token_logo_circle_dark.png",
"svg": "http://token_logo_circle_dark.svg"
},
{
"png": "http://token_logo_dark.png",
"svg": "http://token_logo_dark.svg"
}
]
Thinking now that a rather minimal approach, perhaps allowing for just light and dark mode, would suffice. Something like:
"images": [
{
"png": "http://token_logo-black.png",
"svg": "http://token_logo-black.svg",
"dark_mode": false
},
{
"png": "http://token_logo-white.png",
"svg": "http://token_logo-white.svg", //the white will be visible and contrast nicely against a dark background, which is why the white logo is used for dark mode.
"dark_mode": true
}
]
Another thought is to remove the URL entirely. If/when this registry moves to another location, all the URLs will be inaccurate. In addition, image overrides and image name changes can cause issues. What we can do is allow images to either be assumed to be found within the chain's /images/ folder with an exact name, or to follow and asset's traces (which acts as a linked list) to another location within the registry and find the images for the earlier form of the asset (or go back yet another transition).
"images": [
{
"description": "TOKEN Logo",
"png": "token_logo-black.png",
"svg": "token_logo-black.svg"
},
{
"description": "TOKEN Logo (Dark Mode)",
"png": "token_logo-white.png",
"svg": "token_logo-white.svg",
"dark_mode": true
}
]
another suggestion:
-Images array contains any amount of image pointers and/or asset pointers:
-An image pointer contains: --platform (folder name): required, defaults to *this folder, --name: required, the name of the file(s) contained in the referenced [/images/] folder --description: optional, used to facilitate human reading of the chain registry --dark_mode: indicator of whether the iamge is used for dark mode
-An asset pointer contains: --platform (folder name): required, defaults to *this folder, --base_denom (asset name): referes to the base_denom of some foreign asset, where an asset pointer is used, that asset's images array is inherited (but once a reference turns circular--which maybe a reference of a reference--the referenced set is ignored) *edit, asset points have now been integrated, making this very possible
"images": [
{ // refers to an image in this chain's /images/ folder
"name": "token_logo-black",
"description": "TOKEN Logo (Default)"
},
{ // refers to another image in this chain's /images/ folder
"name": "token_logo-white",
"description": "TOKEN Logo (Dark Mode)"
},
{ // refers to an image in another chain's /images/ folder
"platform": "chainxyz",
"name": "token_logo-white",
"description": "TOKEN Logo (Dark Mode)",
},
{ // refers to all images defined for the GLUON asset of another chain
"platform": "chainxyz",
"base_denom": "ugluon"
}
]
-next iteration idea allows for the "legacy" format, being the URL/URI. -still allows for local file names, and themes -still allows for inheriting another token's images
"images": [
{
"file_name": "axlusdc",
"file_formats": ["png","svg","jpg"],
"name:" "Axelar-bridged USDC (erc-20)",
"description": "USDC token logo with Axelar sub-logo",
"properties": ["light","dark"],
"sub_logo": "Axelar bridge"
},
{
"chain_name": "ethereum",
"base_denom": "usdc"
},
{
"url": "http://raw.github......chain-registry/chain/images/token_logo.png",
}
]
A more recent idea is to just include theme, perhaps by:
"images": [
{
"svg": "${URL_POINTING_TO_CHAIN_REGISTRY}.svg",
"png": "${URL_POINTING_TO_CHAIN_REGISTRY}.png",
"theme": "0x1F0E2D"
}
]
where these is a color and must be an upper case hex code, preceded by '0x'
