ICRC-97: Non-Fungible Token (NFT) Metadata Standard #98
Conversation
Indicate that the minimum list of asset purposes and display types are defined.
Rephrase purpose of ICRC-97.
Mention Value is recursive.
Fix spelling
Fix spelling
Improve phrasing.
Mention future work.
| | external_url | Yes | variant { Text } | string | URL that allows the user to view the item on your site. | | ||
| | name | Yes | variant { Text } | string | Plain text. | | ||
| | description | Yes | variant { Text } | string | Markdown. | | ||
| | assets | Yes | variant { Array = vec variant { Map } } | object[] | List of assets ordered by priority descending. | |
There was a problem hiding this comment.
this allows to provide multiple different assets that belong to a specific NFT, right? I am wondering how consumers would select the "default" asset, or do we expect creators to use the first asset explicitly as preview? I see that there is also the possibility to define a purpose of the asset 🤔
There was a problem hiding this comment.
List of assets ordered by priority descending.
The order of the list of assets matters, dapps are expected to prioritize assets higher in the list.
There was a problem hiding this comment.
so as a consumer (e.g. explorer or marketplace) I would use the first occurrence of an asset with type image (or preview if existing), right? assuming that the NFT has an image attached.
if we can have more than one asset with purpose irc97:preview, I'd expect that irc97:preview differs from its corresponding irc97:image. otherwise the consumer could just resize the irc97:image to the needs.
There was a problem hiding this comment.
I would use the first occurrence of an asset with type image (or preview if existing), right?
Yes, I'll clarify this in the spec a bit further.
otherwise the consumer could just resize the irc97:image to the needs
I'll also clarify in the spec that irc97:image should be used if irc97:preview is missing.
|
|
||
| | Purpose Value | Description | | ||
| |----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | icrc97:image | Original size image that is shown on e.g. item details page. Additional optional `width` and `height` properties define the dimensions in number of pixels. | |
There was a problem hiding this comment.
can you provide an example on how this would be defined?
There was a problem hiding this comment.
I'll add examples to the spec
| | icrc97:property | Shows attribute as property with e.g. rarity, this is the default display type. | | ||
| | icrc97:date | Shows attribute as date, expects epoch timestamp number in milliseconds. | | ||
| | icrc97:time | Shows attribute as date with time, expects epoch timestamp number in milliseconds. | | ||
| | icrc97:rank | Shows attribute as progress rank e.g. 4 of 10, expects number and additional `max_value` property with a number. | |
There was a problem hiding this comment.
can you provide an example on how 4 of 10 would be defined?
There was a problem hiding this comment.
I'll add examples to the spec
| | name | Yes | variant { Text } | string | Plain text. | | ||
| | description | Yes | variant { Text } | string | Markdown. | | ||
| | assets | Yes | variant { Array = vec variant { Map } } | object[] | List of assets ordered by priority descending. | | ||
| | attributes | Yes | variant { Array = vec variant { Map } } | object[] | List of attributes ordered by priority descending. | |
There was a problem hiding this comment.
are the attributes expected to be immutable? otherwise we might want to distinguish between mutable and immutable attributes
There was a problem hiding this comment.
the term "immutable" is of course tricky, given the nature of canisters living on ICP.
did you generally discuss to track the history of metadata changes so far? 🤔
There was a problem hiding this comment.
Good points, there's the update schema in ICRC-7 for the purpose of tracking metadata updates. I'll mention how to make the metadata immutable, basically by not returning above block type in ICRC-3 supported block types. I'll also mention how ICRC-97 metadata updates should be encoded as blobs in the update schema in case the metadata is not immutable.
There was a problem hiding this comment.
I think I need to read more about ICRC-3 🤔
note: the link is not working.
There was a problem hiding this comment.
note: the link is not working.
Fixed
| | Root Metadata Property | ICRC-3 Type | Description | | ||
| |------------------------|-----------------|----------------------------------------| | ||
| | icrc97:metadata | variant { Map } | Contains on-chain metadata properties. | | ||
|
|
||
| Alternatively the following metadata property MUST be defined in the root of the token metadata if we want to return | ||
| external | ||
| off-chain metadata instead of on-chain metadata. | ||
|
|
||
| | Root Metadata Property | ICRC-3 Type | Description | | ||
| |--------------------------|-----------------|---------------------------------------------------| | ||
| | icrc97:external_metadata | variant { Map } | Contains below external JSON metadata properties. | |
There was a problem hiding this comment.
this does not prevent defining both, right?
There was a problem hiding this comment.
The metadata ICRC-3 structure doesn't prevent any dev from not following the spec, but you're right, according to the ICRC-97 spec only of one these should be defined. I'll clarify this in the spec.
| | External Metadata Property | Optional | ICRC-3 Type | Description | | ||
| |----------------------------|----------|------------------|--------------------------------------------------------------------------------| | ||
| | url | No | variant { Text } | URL that returns the metadata in JSON format (protocol is not limited to HTTP) | | ||
| | sha256_hash | Yes | variant { Blob } | SHA-256 hash of HTTP response body bytes returned from above url. | |
There was a problem hiding this comment.
in case the icrc97:external_metadata changes, the hash needs to be updated if provided. right?
There was a problem hiding this comment.
Yes that's what I meant with SHA-256 hash of HTTP response body bytes returned from above url..
I'll clarify this further, keep in mind the hash is optional, so a dev can opt to not have it.
Overall, immutability on the IC is only truly something one could trust if the contract code is public, build are reproducible and the canister doesn't have controllers defined (or blackholed). As I mentioned earlier, some method(s) could indicate that things are immutable, but unless above is true, you can't fully trust it.
No description provided.