Call for Participation: NFT Token Standard Working Group [Status Updated]

Agenda for the NFT Working Group call this afternoon, 2024-03-26:

  • Change for metadata / hash modelling discussed above
  • Getting more participation in the WG for the upcoming work items
    • Broader announcement, e.g., in global R&D, Twitter etc.
    • Concrete calls for action, e.g., feedback on standards
  • Continuing work on ongoing proposals

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.

2 Likes

A few notes from the current draft for when you get back from vacation. Excited to get this to the nns.

  1. 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;
  1. Let’s make sure and get the asyncs in there for all the function return types.

  2. Update ICRC-61 to ICRC-10

  3. On 37 can we call TransferFromResponse TransferFromResult so it is consistent?

1 Like

@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:

  1. Using the explicit record as you suggested it.
icrc7_token_metadata : (token_ids : vec nat)
   -> (vec opt record { metadata: vec record { text; Value }}) query;
  1. 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.

All done now.

Done.

Links

ICRC-7
ICRC-37

2 Likes

I would opt for option 2, to avoid implementations from adding other fields to the record that should have been in the metadata itself.

1 Like

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.

2 Likes

We know have a discord channel to kick off the asynchronous conversation around ICRC-7 metadata standards. Please feel free to join everyone

3 Likes

The ICRC-7 and ICRC-37 standards are close to be forwarded to the NNS for voting. Last chance to comment.

See this post for details: NFT standards ICRC-7 and ICRC-37 ready for NNS vote

4 Likes