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).

[cryptoquick]

Just a couple of spelling change suggestions.

The update on fractional and collectibles is good. 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.

I like the idea of Media for things such as embedded thumbnails. There's no long er an explicit limit on the length of the byte array, however.

Also, a question about Uri... I worry that this could be too brittle. Ideally we'd be able to bootstrap with several Sources-- sources [Source], and it could search for a unique Identifier amongst those sources. An assumption could be made that the Identifier is concatenated to the Source, so it might need to end in a trailing slash. I think an Identifier should be a [Byte] array, so the hash bytes themselves could be compactly-encoded. It could then have a HashType that is u16 that corresponds to this lookup table:
https://github.com/multiformats/multicodec/blob/master/table.csv
(Probably the only thing Protocol Labs ever made that could be remotely useful to us...)

What's nice is they also have Bitcoin hashes, which is good for interoperability across things like @casey's Ordinals project.

Another benefit to separating sources is that they could perhaps be updated by a separate OwnedRight utxo if source URIs ever need to be updated, without updating the hashes. This helps reduce the size and frequency of that state transition, and it also increases trust in that the sources might change over time (decades, centuries?), but the hashes will stay the same.

Additionally, perhaps there could be an array of Attachments, and each Attachment has a role field, which could be a short Ascii string that would label what it's for, some examples on how this would be used would be "Sample" for an audio file, vs "Lossless". For a video, you'd have Cover, Preview, HD, UHD, etc.

[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]

Spotted another mistake

[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 pls check do I match your suggestions with this improvement

[cryptoquick]

Some more review, hopefully this isn't too nitpicky.

One question about Nomination... Is this a reference to Denomination? Nomination is a different word with a different meaning, unless there's an archaic use I'm unfamiliar with.

[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.

[cryptoquick]

Thanks, @dr-orlovsky for the thorough review. I think we've thought through everything I'd like to think about for this.

[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.

[dr-orlovsky]

@fedsten tried to address your proposal with these suggestions - pls confirm if you are ok with them.

I have taken U32 and not U64 for the max token amount, since would like to prevent spamming with NFT transactions. Unlike fungible tokens, non-fungible tokens are transferred one by one (or in fractions), meaning that state transition would have at least one output and one input per each token transferred (!!!), unlike with fungibles. Having trillions of them would grow consignments to enourmous size - and with U32 you already would have up to 4 billion of tokens!

[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.

[dr-orlovsky]

@zoedberg I put your suggestion into the code

[dr-orlovsky]

I had more considerations over overall RGB interface and schema capabilities and put some related fixes to the code: see #137 (comment) explanations; other comments are consequence of this change

[dr-orlovsky]

another small fix