Add media information to RGB20

[dr-orlovsky]

The original discussion started in

@zoedberg> our team would like to propose a change to the RGB20 interface. By adding optional medias and previews it would be possible for us to implement a schema similar to our previous RGB121, that we propose to name CDA (Collectible Digital Assets).
The schema will be very similar to the NIA one but will allow an optional media and an optional preview. This should open interesting use cases like the possibility to add a logo or attach a PDF file to an asset.

@dr-orlovsky> we had this discussion with @fedsten and @giacomozucco back in 2020 and they were proposing to have fungible token media not be a part of the contract. The reason for that is that they are volatile, and may be provided by different vendors (for instance dark backgrounds may require different assets, or they may take different sizes, shapes etc). Thus, RGB20 does not include media for tokens - and instead, it should be a part of non-committable data (like Supplement).

@fedsten> I must admit that I do not remember much of our 2020 discussion, but I do believe there are several use cases that we may not have considered at the time. For example security tokens may want to attached scans of analogically singed legal documents and/or visual representations of the real world asset (e.g. the cadastral plan of a real estate asset, the picture of a tokenized physical artwork etc).

Personally I do not see any drawback in adding an optional media attachment, but in not supporting it I see the risk of limiting some potentially interesting use cases.

[dr-orlovsky]

I'd like to start by clarifying the difference between different types of information which may be present or related to RGB smart contracts.

1. Declaration of a state, code and rules of a smart contract ("schema") - and the contract genesis that fulfils those requirements.
   Everything added into the schema and genesis is the information the contract issuer commits to. It is subjected to be global (i.e. defined for all users and software interacting with the smart contract) and does not change - or change under well-defined rules, by well-defined parties (contract issuer or some delegates) and the change requires an on-chain bitcoin transaction. All users of the contract are notified about a change (by seeing the UTXO controlling that right being spent on-chain) and must react to it.

2. Additional contract metadata - the contract supplement. It is always (re)distributed with the contract as a part of the consignment.
   The supplement is a recommendation to the software and users which may be used in UI or in interpreting/understanding contract semantics and meaning. The contract issuer does not commit to this information to be unchanged and any party can provide its own version of the supplement (for instance, wallet developers may provide their media pack for the token icons for existing contracts). The supplement is signed by the creator, and the user (via wallet) decides which supplement version is used - based on the identity of the supplement creator. For instance, some users may require the wallet to always apply supplements coming from the contract issuers; others - from the wallet developers etc. It is like the "theming" of a contract. Different users may use different supplements (which is not possible in pt.1).

Now, the interface has to do something with only pt1 and not pt2. It declares which state is in the contract, and what semantic meaning this stake has (for instance, state id 2000 is a token ticker etc), nothing more. You may think of an interface as an ERC standard in the Ethereum world.

Each piece of information with a defined semantic meaning must be kept separate. It is impossible to have an "image attachment" in the contract under some interface (RGB20) which in some cases will be a scan of a contract, in others - a token icon etc. If we add a scan of a contract, it is one type of state; if we add a token icon - it is some other.

Finally, a contract may implement multiple interfaces. RGB20 is an "equivalent" of ERC-20, and I think it will be good for interoperability to keep it quite close to ERC-20. However, nothing prevents from creating some other RGBxxx interface defining "images, scans etc" contract information and having some token implementing RGB20 also implementing that RGBxxx. RGB20 must not be a universal interface "for everything" and must have a clear goal and scope.

Now, back to the @fedsten suggestions, I think that:

1. I am fine with adding "attached scans of analogically signed legal documents and/or visual representations of the real world asset (e.g. the cadastral plan of a real estate asset, the picture of a tokenized physical artwork etc)" as a contract state to RGB20. This is unique information which is updated rarely and under a single well-defined party with a right to update it. But: this shouldn't be used as a token icon in the wallet UI!
2. For a coin/token icon (like we have in the coinmarketcap list) we have to use a contract supplement. The contract may have multiple supplements (and variants of icon) - some coming from the issuer, some from wallet devs (to match their UI style, dark/light modes), some from random devs styling token collections etc.

[dr-orlovsky]

In a talk with @fedsten it was decided:

• to add media attachment to RGB20 which will commit to the contract terms
• this media attachment must not be changeable (like contractText), and, potentially, should be combined with it into a single type (like it is done for the ticker and name in DivisibleAssetSpec)

Add asset icons etc to the supplement