The WG had a good discussion on how to model metadata in the ICRC-3 blocks of an ICRC-7 ledger. The discussion was longer and more complex than anticipated and the decision was to ensure that it is guaranteed that the ledger state can always be reproduced from the full block log of the ledger.
See ICRC-7 for the update.
The main change encompassed that we recommend that metadata be expressed always with a Map variant of Value that holds the tuple ("icrc7:token_metadata", metadata), where metadata is the actual updated metadata of the token expressed in a Map variant of Value. It has been phrased that in the absence of any extension standard that is used, the above SHOULD be used. This keeps it open to future extension and recommends this for now in order to keep the ledger state reconstructable.
A few notes from the current draft for when you get back from vacation. Excited to get this to the nns.
This seems a bit off. Is it a vec opt record{metadata: vec record {text; Value}} query? If the record is there and we have to be explicit about metadata, let’s do so.
icrc7_token_metadata : (token_ids : vec nat)
-> (vec opt metadata: vec record { text; Value }) query;
Let’s make sure and get the asyncs in there for all the function return types.
Update ICRC-61 to ICRC-10
On 37 can we call TransferFromResponse TransferFromResult so it is consistent?
@skilesare
Thanks for the valuable comments, Austin! Back from vacation now and finally wrapping this up. The comments are all addressed now, see links below.
Indeed, there is a glitch in the current response type. There are two options to fix this:
Using the explicit record as you suggested it.
icrc7_token_metadata : (token_ids : vec nat)
-> (vec opt record { metadata: vec record { text; Value }}) query;
Omitting the record and keeping it with one less layer of nesting. This may be more consistent with the other responses where we usually don’t introduce a record just for giving a name to the response field, but just have a vec of some type.
icrc7_token_metadata : (token_ids : vec nat)
-> (vec opt vec record { text; Value }) query;
1 is more explicit, 2 is simpler as it has one less level of nesting.
Have chosen Option 2 as it is simpler, but that’s not a strong opinion, just striving for simplicity for an implementation and consistency with what we have. If you have a strong opinion that we should have the record explicit, let me know.
All the Candid functions are by definition asynchronous IMHO, so there is no async keyword in Candid. The async keyword comes into play for Motoko, though, but we don’t specifically use Motoko syntax in the API spec here.
What do we want to put on the agenda for the meeting tomorrow? ICRC-7 and ICRC-37 should not require further discussion, unless you have something on your minds. @skilesare, @sea-snake, @benji, @kayicp, all
It may be good to look and see if we have any blind spots. Did icrc7 end up not covering something that a disconnected person would have expected?
For example, one thing that jumps out to me is that we purposely ignored something like standard metadata for a token that a marketplace might expect. This also may be a good place to get some marketplaces involved in the WG.
We haven’t received much feedback in the above forum topic on the soon-to-be-released NFT standards. The commenting time was now one week, which should be sufficient for anyone to raise issues, which has not happened. In my view, we can go ahead with an NNS vote shortly.
For tomorrow’s meeting of 2024-04-23, my only agenda item is:
Deciding whether to move forward with an NNS vote for ICRC-7 and ICRC-37
If people here in the group have any other suggestions for items and can prepare something, please let me know. I currently don’t have time to prepare something. In case of no other suggestions, we can make it a short meeting.
@dieter.sommer I’m not a frequent attendant at this meeting but I support everything yall do.
Unfortunately I have a lot of concerns about the current ICRC-8 spec. I’m not sure how mature the spec is but I would like to discuss these concerns with the group.
I am planning to type up my comments this evening. Just wanted to give a heads up.
Thank you for your comment that you intend to provide! Any constructive input is appreciated and helps make the results stronger! Also note that ICRC-8 is still in an (early) draft stage.
A couple of outstanding questions for us to answer(maybe before the next meeting even):
What to do about the follow/no follow data tags.
Do we split out the ic-http URI schema into its own ICRC? Is it useful elsewhere?
Some helpful things if people what to get involved
Work up some examples of what metadata would look like under different scenarios. Implementation exposes issues with our standards.
Work on the OpenSea, Enjin and IC based standards. Here is what I removed:
When using the direct value method for metadata (`icrcX:metadata:value`), the following standard items are recommended within the metadata map:
- `icrcX:name`: Text — Name of the NFT.
- `icrcX:description`: Text — Description of the NFT.
- `icrcX:image`: Text — URL or data URL pointing to an image representing the NFT.
- `icrcX:preview`: Text — URL or data URL pointing to a thumbnail image of the NFT.
- `icrcX:experience`: Text — URL or data URL pointing to a dapp for interacting with the NFT.
- `icrcX:attributes`: Array of Maps — Each attribute is a map containing properties like trait type, value, and display type.
#### JSON Format Compliance
When metadata is represented in JSON format (either embedded or via URI), it should adhere to widely accepted standards such as those established for ERC-721 or ERC-1155:
- The JSON structure should generally omit the "icrcX:" prefix used in direct value maps.
- An optional field, `icrcX:metadata:format`, may be used to specify the metadata standard or version being followed (e.g., "erc721", "enjin", "opensea").
