Publishing asset metadata

[green adder]

Are there any plans already on how asset meta-data is to be published for soroban assets?
Should .toml files be used or does everything (incl. asset image) come from contract storage?

[near gyro]

There’s this at the bottom of https://soroban.stellar.org/docs/common-interfaces/token

#[soroban_sdk::contracttype]
pub struct TokenMetadata {
    pub name: soroban_sdk::Bytes,
    pub symbol: soroban_sdk::Bytes,
    pub decimals: u32,
}

[green adder]

Right.
But what about the other fields we know from SEP-0001 [[currency]] section?
Especially the image.
Also as arbitrary data can be stored with a contract (or token for that matter) – the account's data fields are in classic used to link to IPFS (in case of NFTs) – external data links can be stored with the token as well. Has there been discussion about a best practice for that yet?

[brittle pasture]

AFAIK no. There will be assets that might not want to follow the classic Stellar way of doing things, tho, as they won't want to be tied to an owned domain via a TOML. If the token admin is a Stellar Account, would the current sep be sufficient?

I imagine a ERC-721 like metadata extension might be a better way to define NFT images in the Soroban world (though, would be worth doing some research to see if better ways have been established)

[green adder]

opensea suggests adding a CID to a json on IPFS that describes everything for example.

still one question regarding the asset-image in general remains: should the TokenMetadata be augmented with at least that field as probably every asset-issuer would want to ba able to provide a visual representation of their asset.

[brittle pasture]

Hm, I'm generally pretty against storing unnecessary info on chain, and I think name and symbol fall into the same category as a token icon.

I think a proposal to update this should replace name and symbol with some sort of optional metadata augmentation that includes an icon.

While what you say is true of fiat and asset-issuer tokens, I don't think its generally true that ALL tokens want an icon, especially procedurally generated ones like Uniswap LP pools.

[left kernel]

I wanted to chime in and mention that TokenMetadata and the init method were removed in the upcoming release. The reasoning was that contracts should be able to customize initialization without breaking the token interface.

[green adder]

Good point. I was focused on user-facing asset tokens. So probably something generic similar to classic's data fields would be better for the token interface? If so: instead of a property of type TokenMetadata the interface could just store a Map<Symbol, Bytes> as data field or similar.

[green adder]

I think that is a good idea. Still I think I would keep the TokenMetadata type in the interface so if people want to implement it, it's consistent by pre-existence and not only by convention that builds over time.

[left kernel]

The decimals, name, and symbol functions are still in the interface, which I think is sufficient to implement. TokenMetadata was specified previously because it was a parameter to init, but with that method removed, I don't really see the need to specify a type that may or may not be used.

[green adder]

True. There is no enforcement of using the type when it's not actually used by the interface itself...