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

Comments on the draft of May 21 for ICRC-76

@skilesare, thanks a lot for the write up, this is already very nice! With the changes from the recent meeting it has really become very powerful, yet simple.

Some comments that we may want to discuss towards finalizing it follow below. We may want to cover some of those in the meeting this afternoon.

  1. Editorial: “Metadata is hosted externally”. 2. This is not true for data URIs, we need to rephrase this. E.g., “Metadata is accessible via a specified URI, which can either be a pointer to a JSON file hosted externally or a data URI as specified in RFC 2397.”, or similar.

  2. We should make explicit how a URI for URI-based metadata is expressed through a Value.

  3. Maybe we should make explicit that any valid URI can be used and that the presented examples are the major prominent examples of schemes, but not exhaustive.

  4. ic-uri seems to be a concept that is valuable also outside of this domain. The question is whether a generic standard would require further refinement. If so, we may want to refrain from making it separate now in order to not try to boil the ocean, but include it here and maybe factor a generalized variant out in the future as a separate ICRC.

  5. Is the IC-URI only intended to address resources exposed through the http_request method of canisters? If so, would a URI scheme that addresses the native canister interface also be useful?

  6. Mixing the approaches of representing metadata should be allowed, e.g., to have small metadata items directly expressed, but large ones like images linked via URL. This may be a prominent use case for practical scenarios. Making explicit that this is possible would be geat (if we agree that it is). We should present the structure how this would look like. Also, allowing for multiple metadata references may make sense, e.g., to combine metadata from different external locations. This is currently implicit (or even unsupported), but something that we may want to have.

  7. Overall, we may want to make the difference between URI and URL more explicit. URIs are not followed, they are merely an “Identifier” (the “I” in “URI”). URLs are followed, the “L” stands for “Locator” in “URL”.

  8. URI-based metadata can again point to further metadata items, like images in a remote JSON file. This makes following recursive. We should make this explicit, otherwise it seems that there is only one level of following indirection.

  9. Some outstanding questions on what to do about data in metadata that is Text, a URI, but NOT supposed to be traversed and included in the metadata. (Choice one is to have a specific tag in a map for this type of data ie icrc76:no_follow or two to have a tag for followable links ie icrc76:metadata:follow).
    → URIs are often used as identifiers that are not followed because URIs are essentially the only reasonable global namespacing system, so not following may be the default case without a tag, while following having a tag “icrc76:metadata:follow” might make most sense.

  10. We may want to reserve already an ICRC number for the OpenSea-specific standard and maybe others as well.

Note that we have a new Zoom link for the WG in the calendar.

It’s still an old link on my end :confused:

New Zoom link: Launch Meeting - Zoom

Aus @skilesare is still out on vacation I suggest we drop the call this afternoon.

1 Like

All calendars should now reflect the correct Zoom link. Apologies for the issues recently of having an outdated link in the invitation.

hi @dieter.sommer
i suppose we can update the status to Accepted now that it has passed the voting stage, yes?

3 Likes

@dieter.sommer @sea-snake

I took a stab at Reserved For Large Metadata Handling in Transaction Logs · Issue #61 · dfinity/ICRC · GitHub and then 76 uses it here: Proposal for initial best practices for ICRC7 metadata · Issue #76 · dfinity/ICRC · GitHub

1 Like

Had forgotten to change this, but it has been changed earlier this afternoon.
Thank you for the reminder. :slight_smile:

1 Like

@skilesare @sea-snake

I drafted the ic-http URI scheme for addressing canister-hosted HTTP content, you can have a look at it in Issue-91.

Feedback is welcome!

2 Likes

The WG meetings are recorded from now on. You find the recordings in the following Google Drive: NFT working group - Google Drive

1 Like

Please find the slides and recordings of the meetings here.

Meeting of 2024-07-30

Please find the slides and recordings of the meetings here.

Meeting of 2024-08-13

1 Like

Please find the slides and recordings of the meetings here.

Meeting of 2024-08-20

1 Like

@skilesare, @sea-snake

Regarding ICRC-91, there is a close relation to the work on CNS. Don’t have time currently to investigate further, but it may be that this already captures what ICRC-91 was intended for.

I don’t really see anything here about canister URLs. Maybe as far as registering a domain to map to a canister?

Investigated this further with @Kepler who pointed me to this and is one of the main implementers of it. What you can do with CNS is to assign a name in the CNS system to the canister. The name can also be switched to another canister in case this is needed, e.g., for data migrations. This latter part is more powerful of our ic-http proposal.

You can, I think, use that name in a URL to refer to resources independent of a boundary node, both on and off chain. This part still needs to be clarified, not 100% sure about it.

Now if you accept that with CNS you need to assign a name to a canister, you can achieve something similar as we do with ic-http, namely refer to resources independently of boundary node hostnames. A major difference being that it does not use HTTP-exposed resources, but resources exposed through the regular protocol.

So the question now is how far this covers what we want.

@skilesare, @sea-snake: I need to give a presentation tomorrow during the time of the WG meeting and therefore cannot make it to the meeting.

1 Like

Hi @skilesare, @sea-snake, everyone! Do you have specific agenda items for tomorrow’s NFT Working Group meeting on your mind? Thanks!

Hey @dieter.sommer, we still have a discussion on the ic-http standard and we need to take steps regarding metadata.

1 Like