Rewrite RGB21 spec using Contractum & concept of interfaces

[dr-orlovsky]

Also asking @cryptoquick to review (can't add him to reviewers without him joining this github org first - invite sent).

[dr-orlovsky]

Thank you for spotting misspellings! Committed them.

On your topics:

I also like that each collectible can be enumerated, such as like for baseball cards or vehicle VINs, though ideally this would be an Ascii string and not a U16.

Each token is a data structure, which includes many fields, among them external attachments or URLs (see Token data type). What you call U16 is a reference to that token (Token.id field, specifically) which allows state transitions/engravings to link to one of the issued tokens not replicating all of its data.

There's no long er an explicit limit on the length of the byte array, however.

Sorry for confusing, there is: with the Contractum language (and strict encoding type definitions) each array, unless specified otherwise, is restricted to u16::MAX items (~64k), i.e. assert! [Ascii] =? [Ascii ^ 0..0xFFFF] holds.

On the sources/attachments/URLs I will comment separatedly

[dr-orlovsky]

On URIs:

1. It is a URI, not URL (see the last letter), meaning that it can be, for instance, a URN (like urn:isbn:0451450523, urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 or even urn:sha256:76adf28a47b3d51a0eb772bd8b2812aa327c9a773e59475b2b6137af6f5948f4)
2. I think URN is much more standard than multicodecs (while allows to do the same things). Multicodecs I do not like due to several reasons:
   • dependency on an external registry by a shitcoin/ICO-related organization which can be shut down any moment
   • non-standard
   • uses variable integer encoding, prohibited in RGB / strict encoding
3. I like the idea of the allowed sources list, which, if we continue to use URI could be a domain names or URN namespaces matched against URI. From what I read from your comment it should cover your requests.
4. Not sure I fully understand what attachment means. Are you saying about tokens (potentially) having multiple auxillary external resources/files linked?

I will work on the sources part

[dr-orlovsky]

@cryptoquick committed changes which are non-questionable, to focus on remaining questions

[dr-orlovsky]

@cryptoquick seems we are lost in terminological differences.

For me, RGB21 interface <-one-to-many-> schema <-one-to-many-> contract instance <-one-to-many-> token <-one-to-many-> attachment/media.

• RGB21 is interface; it defines the way how wallet and user interacts with a class of contracts, i.e. shapes user interfaces and assigns semantics to the contract state and operations
• Specific schema implements RGB21, i.e. provides a business logic how the contract exposing NFT UI behaves in internal details. For instance, some schema may require reserves locked when NFTs are issued, some others do not.
• A contract issue is created by the NFT producer (artist, publisher etc). It deals with a set ("collection") of art elements / digital rights over digital media, each of which is unique, non-fungible - and, sometimes, might be shared across many owners ("fractional").
• Each token is an item (digital rights over some art item) which can be owned by a party (or a set of parties, as multisig or in shared way in case of fractional media). It can be transferred
• An attachment/media is a specific file representing content related to a token. Each token can have multiple types of associated content, but usually a unique file for each type (for instance, for a song it can be audio file, lyrics, cover image; for a book it can be a cover page, epub, pdf etc).

The only thing which is external to the contract is an attachment content (last thing). I.e. each token may have relation to multiple external files. These files are identified by a hash of the data; i.e. hash of the data can't be ever changed for each specific attachment, i.e. it is a property of attachment (and not a contract, channel/source, token or anything else). What can change is the channel via which the file is accessed. Thus, I propose to have three distinct things:

1. Recommended channels of retrieving attachment ("sources") - it is always a form of URL using different protocols. It is not a complete URL and must be extended with the hash of specific attachment
2. Hash of specific attachment which commits to its content. It is part of immutable Attachment structure.

For instance, a contract may have two sources:

• https://some-producer.com/tokens/
• storm://61f401464c53b301cb931909f463455dc2c1a4370cd96bcacd3f57d84a2bfb87@32zzibxmqi2ybxpqyggwwuwz7a3lbvtzoloti7cxoevyvijexvgsfeid.onion/

and a token having two attachments:

• 2a290afc93309fffe510309e31213658726e5832a1ec6597720a5a50513cf47a
• e3a3025e9ec03433d9f17b132a4aea5a02491bcedcd1f31e87684fa7e439b16b

Which will result in four addresses which can be used for content retrieval:

• https://some-producer.com/tokens/2a290afc93309fffe510309e31213658726e5832a1ec6597720a5a50513cf47a
• https://some-producer.com/tokens/e3a3025e9ec03433d9f17b132a4aea5a02491bcedcd1f31e87684fa7e439b16b
• storm://61f401464c53b301cb931909f463455dc2c1a4370cd96bcacd3f57d84a2bfb87@32zzibxmqi2ybxpqyggwwuwz7a3lbvtzoloti7cxoevyvijexvgsfeid.onion/2a290afc93309fffe510309e31213658726e5832a1ec6597720a5a50513cf47a
• storm://61f401464c53b301cb931909f463455dc2c1a4370cd96bcacd3f57d84a2bfb87@32zzibxmqi2ybxpqyggwwuwz7a3lbvtzoloti7cxoevyvijexvgsfeid.onion/e3a3025e9ec03433d9f17b132a4aea5a02491bcedcd1f31e87684fa7e439b16b

[cryptoquick]

That's perfect! This will be a usage convention we'll definitely want to document.

[fedsten]

Overall the proposed specification looks very good to me, I just have a couple of small feedback:

1) > -- collectibles are usually scarse, so we limit their max number to 64k data ItemsCount :: U16

I wouldn't limit ourselves with this assumption, in the physical world there are plenty of collectibles that are created in much larger amounts than 64k units (e.g. some Pokemon cards have been printed in the order of millions), and also in the context of gaming I would expect some collectibles to be printed in very large quantities. I suggest therefore to increase it to U64 as we have in RGB20.

2) As @cryptoquick already pointed out, the wording Nomination/Renominationis a bit confusing, as it is usually used to indicate the act of appointing someone to something, not to assign an identifying name to something as in this context. I think we can change it with Naming/Renaming or something along those lines.

[cryptoquick]

True. U32 is a good compromise, as far as I know, there's no single product model I know of that has shipped more than 4 billion units.

[dr-orlovsky]

@cryptoquick @fedsten I propose to merge this if you do not have any other comments

[zoedberg]

@dr-orlovsky sorry for being late, I'll do a review by the end of today, could you please wait until then?

[zoedberg]

data Source :: url(Proto, Dns) | urn(UrnPrefix) | storm(NodeAddr)

data Proto :: http | https | httpxk | ws | wss | wssxk

I don't think that url(Proto, Dns) will be enough to understand how to retrieve the data. There are no unique standards to transfer files via http or ws.

Couldn't we remove the Source from the contract, keeping that as it was before (FieldType::NftSource was just a hash of the data)? I think that we could use the RGB invoice (https://github.com/LNP-BP/invoices) in order to specify to the receiver where the consignment and media file can be found, specifying the consignment_endpoints. And if someone sees any use case, we could also add a different field from consignment_endpoints, like media_endpoints.

The reasoning here is that a media could change source, it's impossible to guarantee that a DNS will be valid forever, so I don't think this should be included in the consignment.

[cryptoquick]

That's a pretty clever solution, @zoedberg. I like it. It'll make sense to have multiple attachments by their Id, format, and purpose, but omitting the actual source could work so long as a source that's valid for that ID is provided in an invoice as a sort of formalized request format.

[dr-orlovsky]

@zoedberg good point. The asset can be provided not only by the creator, and it is not the issue who has to control the distribution of the asset once it is out. Since the token unique id is already there (it is the attachment id), we can remove Sources and related rights altogether.