Pragmatic naming layout
stas opened this issue · 11 comments
Less of a feature request, but more of a curiosity after reading https://static.optimism.io.
Have you guys considered using a different naming layout to support more pragmatic assets/logo discovery?
We've switched our token assets to use the SmolDapp's layout since it's more intuitive and allows for an open collaboration across projects (atm it's Yearn, Velodrome, smold.app/tokenlistooor):
https://github.com/SmolDapp/tokenAssets
Thanks in advance for reviewing this.
This issue has been automatically marked as stale and will be closed in 7 days if no updates
Bump
Hey Stas!
Thanks for the issue and apologies for the delay. Currently we're using the Uniswap standard.
If we decide to migrate can you share more information: what was the impact of switching your SmolDapp's layout and how does it enable for open collaboration across projects?
I believe we need to address separate concerns here:
- token assets handling and collaboration (opens up for more decentralization)
- token list curation
SmolDapp came up with the idea of separating these two concerns. The second part is up to you and everyone, in fact they do still use the same Uniswap standard you've shared, but provide tools to help curate/re-use these tokenlists. So in this regard, we're probably not discussing new things/changes.
The concern I wanted to bring up is related to the token assets handling and collaboration. I think this should be
- as permissionless as possible and allow anyone to submit their token address mapped to a token logo via a canonical naming layout
- allow tokenlists and non-tokenlists projects reuse these assets by directing token asset discovery towards CDN mirrors serving these assets via the same canonical naming layout
The canonical naming layout for the assets is
token/[chainID]/[tokenAddress]/[fileName].[ext]
Which is something superior to the current layout this repository uses
data/[symbol]/logo.png
By using a canonical and pragmatic naming layout we make the assets discovery very simple and more importantly unified (which can work for any dapp deploying on OP Stack) vs. having them to deal with the hassle of maintaining their own assets or waiting for this repository maintainers to address a PR/keep things in sync.
Velodrome tokenlist is powered by an on-chain governance-based listing functionality, but we wanted to display the assets/logos even for the tokens we didn't "whitelist". We opted out of using the centralized tokenlist for that reason, and to load a token logo we have something as simple as this component that will identify the token logo based on the chain and it's address and resolve to one of the either SVG/PNG images with a fallback image.
Below is a simple implementation I'm sharing as a proof of concept:
import { utils } from "ethers";
import { Img } from "react-image";
import {
DEFAULT_CHAIN,
NATIVE_TOKEN,
NATIVE_TOKEN_LOGO,
TOKEN_ASSETS_CDN,
TOKEN_ICON,
} from "../constants";
export default function TokenAvatar({ address, className = null }) {
if (!address) {
return <></>;
}
const lowcase = String(address).toLowerCase();
const checksum = utils.isAddress(address)
? utils.getAddress(address)
: lowcase;
const classNames = className
? `${className} rounded-full bg-gray-200 dark:bg-gray-700 hover:opacity-80`
: `w-8 h-8 rounded-full bg-gray-200 dark:bg-gray-700 hover:opacity-80`;
if (lowcase == NATIVE_TOKEN.address) {
return <Img className={classNames} src={NATIVE_TOKEN_LOGO} />;
}
// Builds a list of potential CDN logo URIs
const logoURIs = TOKEN_ASSETS_CDN.map((cdnUri) => [
`${cdnUri}/${DEFAULT_CHAIN.id}/${checksum}/logo.svg`,
`${cdnUri}/${DEFAULT_CHAIN.id}/${checksum}/logo-128.png`,
])
.flat()
.concat([TOKEN_ICON]);
return <Img className={classNames} src={logoURIs} />;
}This issue has been automatically marked as stale and will be closed in 7 days if no updates
Bump
This issue has been automatically marked as stale and will be closed in 7 days if no updates
This issue was closed as stale. Please reopen if this is a mistake
Sorry for letting this go stale. Thanks for the thorough explanation. I do agree that the naming layout for our repo could be improved upon. We try to make adding a token as permissionless as possible, and new tokens only have to pass our automated checks (with the exception of Base tokens, which have to go through a separate review process).
The naming layout is only used for adding new tokens to the repo and the idea was that this layout made it easy for contributors to add new tokens. The final output of the token list is generated from the token directories in the repo and complies with the Uniswap standard: https://static.optimism.io/optimism.tokenlist.json. The schema for this standard makes it simple to find a token based on the token address and chain id. The idea is that consumers of the tokenlist should be using the final tokenlist output and should not be fetching token information using our directory structure. Additionally, every time a new token is merged into the repo we release an update of our tokenlist npm package so that apps can integrate our tokenlist without needing to fetch from a CDN: https://www.npmjs.com/package/@eth-optimism/tokenlist.
Hope this helps clear things up for you and again apologies for the delayed response.
We try to make adding a token as permissionless as possible, and new tokens only have to pass our automated checks (with the exception of Base tokens, which have to go through a separate review process).
To be honest I don't see how the current setup will scale. I'd consider looking into organizing things based on chainId/address/logo.svg or just adopt/merge with smoldapp's project. Just based on the response times here, seems like having Velodrome+Yearn is already a better setup in terms of helping a project like this.
Will leave this up to you obviously. Appreciate taking the time to look into the issue 🙏
Thanks for the feedback @stas! I think you made a lot of good points and will consider in future if we ever revamp the tokenlist schema