RGB-21 Schema: Custom token data formatting

[UkolovaOlga]

Question was raised during the dev call held on the 25.11.2020 LNP-BP/devcalls@1fbb7e7

This issue is a part of discussion #79

Intro

One of the questions that need to be covered is what and how makes the token unique.

In RGB, you are able to assign arbitrary data to each of the issued assets, thus each NFT under the contract has some blob (binary data) up to 64kB of size, that is unique to it. What this data is depends on the issuer. First of all, if you need more than 64kB, you can use this data as a pointer to some URL or external source, where much larger data can be downloaded, but it will be your responsibility to maintain this resource alive. Also, it can be IPFS link or torrent link, and it is recommended also to provide the hash of the data (not required for IPFS, but required in case of common link) to make sure that the data was not modified. Or if you need the data to be dynamic and updated, you can provide the URL without hash.

So, the format if this unique token data is completely up to the issuer. And we have a special field of 16 bit integer length that identifies which format is used. Thus, issuers will be able to register their formats via assigning a random 16bits integer number to their format (as a unique format identifier) and make it a part of RGB-21 standard so that the wallet developers could know to parse this constant data (if they would like to display this custom data on top of displaying the token ID).

Questions that remain

Do you find this approach efficient? If not - what might be the alternatives?
Which are the most common formats that we potentially can provide as initial set?

For example, we can limit the data only to the image format or something specific, but we think the system should stay as opened as possible. Maybe it's worth to provide the initial set of formats (image, text ones etc) and leave the rest to the developers to propose their own custom formats.

[cryptoquick]

Would it make sense for the 16-bit field to have an associated lookup table for mime types? Or would it make sense to make it a string field, and have the mime type there? The 64KB content could be identifiable by a magic number, maybe. It might also make sense to revisit the metadata discussion we had earlier, I believe this was on the RGB21 Contractum spec.

[dr-orlovsky]

I think this issue is heavily outdated and not there anymore with what we have in #137

NFT token is made unique by an operation output which issued it.