Consider simplifying MT Metadata structure

[telezhnaya]

I haven't found any details here #245

We have 5 different functions for MT metadata 🤯 https://github.com/near/NEPs/blob/master/specs/Standards/Tokens/MultiToken/Metadata.md

As the smart contract developer, I'd expect 2 structures: contract-wide and token-wide.
As the web developer, trying to show the tokens to the users, I feel absolutely lost. Do I need to call all the 5 methods? Where do I need to show each piece of the info?

Why do we decided to split the data to MTBaseTokenMetadata and MTTokenMetadata? It looks like it's actually should be one object.

Why doesn't MTContractMetadata contain icon and other important fields? See NFT Contract Metadata as the reference.

Are we still allowed to rework this part of the standard, adding breaking changes, dropping some methods and reworking things?

cc @zcstarr @frol @MaximusHaximus @jberrytech @BenKurrek

[zcstarr]

Not sure if details just got lost with time. You could probably rework somethings there's a PR near/near-sdk-rs#776 already floating, but noone has had time to review it from standards team. I'd figure out what the process should be that Jay setup.

The way to think about mt is in tiers. A multi token contract has many tokens vs just one. You need a way to represent these tokens in the same contract (MTBaseTokenMetadata). ContractMetadata as a field only can relay information about the protocol in use and the title for this particular MultiTokenContract.

Furthermore with multi token contracts, there has to be a way of grouping token ids. In the 1155 standard this was done by suggesting a hexadecimal format for cross associating tokens.

I.e. your contract has a golden flame nft and 5 editions of it or you want to link metadata for your token across a set of tokens , the id: string, // required a unique identifier for the metadata field in MTBaseTokenMetadata allows you to do this.

Why separate data structures still. Well people(wallet team initially etc...) want to be able to enumerate over the set of nfts/fts/other in the contract, and retrieving back every instances full metadata could become somewhat infeasible. So having a way to retrieve a subset of the information is important . This was decided after meeting with the stakeholders at the time.

function mt_metadata_contract(): MTContractMetadata {}.
 // Give me just the name and spec

function mt_metadata_token_all(token_ids: string[]): MTTokenMetadataAll[]
// Give me all the metadata for a set of token id so class and instance much of which might be duplicate base data

function mt_metadata_token_by_token_id(token_ids: string[]): MTTokenMetadata[]
// give me the specific instance data about the token, assumes you already know the "group/collection of tokens you're referencing"

function mt_metadata_base_by_token_id(token_ids: string[]): MTBaseTokenMetadata[]
// give me all of the base metadata based off of the token ids I have . Fetch all the collection metadata we have for these tokens 

function mt_metadata_base_by_metadata_id(base_metadata_ids: string[]): MTBaseTokenMetadata[]
// give me all the base metadata for these specific ids. 

Does this clarify a bit why the methods and the data structure ? It's verbose but covers the cases.

MTBaseTokenMetadata - Is essentially the high level data that describes a ft/nft collection ( a class)
MTTokenMetadata - is an optional instance specific metadata ( a specific instance)
MTContract - is just metadata about the over all mt contract

Feel free to drop new thoughts here or alternatives, perhaps you have some weight to start the standards review process for the existing PR(near/near-sdk-rs#776) ?