ZRC-7: Call for feedbacks

[bb111189]

We are seeking feedback for ZRC-7 before we formally standardize it. Please use this thread for discussion

[suenchunhui]

Hi zilfam,
great effort guys.
A few thoughts:

1. since we are re-writing the standards, should we consider having multiple resource and resource_mimetype pairs, so that it's possible to have some kind of fallback mechanism?

2. the standard should define clearly the display priority between animation_url vs resource. I do hope that in the long-term future, we can create NFT with more built-in utility, potentially using some kind of user interaction. (inspired by https://ether.cards/ )

3. we could potentially link the NFT back to an on-chain actionable transition, to provide more utility for the NFT owner, eg. :

{
   ...
   "owner_actions": [
      { transition: "ClaimReward", argument: "String" }, ...
   ],
   "user_actions": [
      { transition: "UpVote", argument: "Uint32" }, ... 
   ]
}

where ClaimReward and UpVote are transitions in the NFT contract
and these can be rendered as buttons that are actionable by owners or other users ....

4. Would having the entire tokenURI being encoded as data:application/json;base64 be supported, and also the resource being encoded as data:image/<mime-type>, to support a fully on-chain metadata, as was done in https://onchainmonkey.com/ project.
   Since data storage on zilliqa is much cheaper in terms of gas, this is potentially much more viable on zil.

I do hope we can set a new frontiers even beyond what is already done in ethereum community!
Chunhui here from https://twitter.com/beanterragame

[bb111189]

1. since we are re-writing the standards, should we consider having multiple resource and resource_mimetype pairs, so that it's possible to have some kind of fallback mechanism?

Thanks for the suggestion. It is a good point and I am in favor of it for future proof and it can provide more flexibility.

[bb111189]

3. we could potentially link the NFT back to an on-chain actionable transition, to provide more utility for the NFT owner, eg. :

{
   ...
   "owner_actions": [
      { transition: "ClaimReward", argument: "String" }, ...
   ],
   "user_actions": [
      { transition: "UpVote", argument: "Uint32" }, ... 
   ]
}

where ClaimReward and UpVote are transitions in the NFT contract and these can be rendered as buttons that are actionable by owners or other users ....

We like the idea and we think it should have the following information

1. Transition name
2. Argument type
3. Argument value (optional)

I can imagine a game, where the token holder owned a token, for example, bear#123, and want people to upvote his bear. It will be useful to also provide the value (or suggested/default value).

"transitions": [
    { "vname": "GM", "params": [] },
    {
      "vname": "UpVote",
      "params": [{ "vname": "token_id", "type": "uint32",  "default_value": "123" }]
    }
]

However, on the different types of actions, it might be too restrictive to classify them into "owner_actions" and "user_actions" as there can be many different types of actions and it will not be possible to define all within the standards.

One thing we could do is to add an optional "tag" and it will be up to the specific DApp or Frontend to decide on how to make use of such information

[bb111189]

2. the standard should define clearly the display priority between animation_url vs resource. I do hope that in the long-term future, we can create NFT with more built-in utility, potentially using some kind of user interaction. (inspired by https://ether.cards/ )

Unfortunately, the context will be important and such priority can differ from token to token, marketplace to marketplace. I think we should not be enforcing a priority here.

[x0rb0t]

I suggest support "data uri" as well:
data:application/json;base64,ewogICJuYW1lIjogIkNyZWF0dXJlICMxMDEiLAogICJyZXNvdXJjZSI6ICJpcGZzOi8vUW1aSUxHYTd6WFViaXh2WUpwZ2tSa2FTQ1lFQnRTd2dWdGZ6a29EM1lrTnNFMSIsCiAgImF0dHJpYnV0ZXMiOiBbCiAgICB7CiAgICAgICJ0cmFpdF90eXBlIjogIkJhY2tncm91bmQiLAogICAgICAidmFsdWUiOiAiQmxhY2siCiAgICB9LAogICAgewogICAgICAidHJhaXRfdHlwZSI6ICJFeWVzIiwKICAgICAgInZhbHVlIjogIkJpZyIKICAgIH0sCiAgICB7CiAgICAgICJ0cmFpdF90eXBlIjogIk1vdXRoIiwKICAgICAgInZhbHVlIjogIkdyaW4iCiAgICB9LAogICAgewogICAgICAiZGlzcGxheV90eXBlIjogInRpbWVzdGFtcCIsCiAgICAgICJ0cmFpdF90eXBlIjogIkJpcnRoZGF5IiwKICAgICAgInZhbHVlIjogMTU0NjM2MDgwMAogICAgfQogIF0KfQ==

[bb111189]

For data URI, possible to elaborate on some of the possible use cases

[x0rb0t]

1. On client App you dont have to make 2 requests 1 - for metadata and then - for resource.
2. In case if you store image as base64 data (small optimized image) you can store and fetch entire data just by single request to zilliqa api and don't use any 3rd-party services, like @suenchunhui mentioned " https://onchainmonkey.com/ project."
3. Indexer, parser, block explorer can grab metadata faster and safer.

[x0rb0t]

4. data uri is valid scheme defined in RFC 2397, and supporting this schema would be a good standard to follow.

[bb111189]

Data_URI seems more relevant for ZRC-6 rather than ZRC-7 as ZRC-7 is supposed to be for off-chain metadata.

Also, a seasoned developer, they will be storing optimized images, but junior dev may not know the intention and end up creating bloated contracts, which will not be healthy for the ecosystem overall.

[x0rb0t]

I think we should not restrict developers of storing data directly in the contract on standard level by following reasons:

1. Mint transition has gas limit, so developer will be able to store only limited amount of data anyway
2. If data stored in the blockchain it creates more value then storing it in the ipfs or some off-chain server (in my opinion)
3. It is RFC 2397 , supported by modern browsers
4. Nothing except gas limit/price can prevent of creating "bloated" contracts - but this will create limitation for developers and artists.
5. burning such NFT will destroy data itself (it can be good for marketing perspective)

[suenchunhui]

5. The ability to do localization suggested in ERC1155 might also be a useful feature, to be more inclusive of different languages:
   https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1155.md#localization

[bb111189]

We have omitted it out in ZRC-7, so as not to overcomplicate the ZRC. Localization can be a new standalone ZRC, appending on top of ZRC-7.

[aj-maz]

There should be an option for secondary resources. It's very useful for example for music NFTs. This way they can also have a cover image for their NFT.

[bb111189]

We are likely to add support for multiple resources but for music NFT, I think the information can be part of the attributes and can be quite expressive over there

  "attributes": [
    {
      "trait_type": "cover_page",
      "value": "https://somelink.com"
    },
    {
      "trait_type": "back_page",
      "value": "https://somelink.com"
    },
    {
      "trait_type": "lyrice",
      "value": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi"
    }
  ]

[suenchunhui]

if that's the case, it might be useful to attach a mimetype?

[aj-maz]

@bb111189 yeah, it makes total sense.

[bb111189]

if that's the case, it might be useful to attach a mimetype?

@noel-yoo I think we can consider adding minetype. However, it might conflict with the display_type

One way to go about it is to, extend display_type to

• timestamp
• resource

If it is a resource, the user can optionally add a minetype

[ghost]

Yes, sounds good.

[x0rb0t]

Also wanted to add one note regarding data_uri.
For application/json metadata data_uri also can be text-encoded like following:
data:application/json,%7B%22name%22:%22Legend%20Ticket%22,%22resources%22:%5B%7B%22uri%22......
Which can be encoded encoded/decoded like following:
token_uri = 'data:application/json,'+encodeURI(JSON.stringify(metadata));
decoded = JSON.parse(decodeURIComponent(token_uri.substring(22)))
It can save even more space for encoded metadata