Closed dr-orlovsky closed 1 year ago
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
On URIs:
urn:isbn:0451450523
, urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
or even urn:sha256:76adf28a47b3d51a0eb772bd8b2812aa327c9a773e59475b2b6137af6f5948f4
)attachment
means. Are you saying about tokens (potentially) having multiple auxillary external resources/files linked?I will work on the sources part
@cryptoquick committed changes which are non-questionable, to focus on remaining questions
@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
.
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:
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
That's perfect! This will be a usage convention we'll definitely want to document.
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
/Renomination
is 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.
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.
@cryptoquick @fedsten I propose to merge this if you do not have any other comments
@dr-orlovsky sorry for being late, I'll do a review by the end of today, could you please wait until then?
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.
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.
@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.
Also asking @cryptoquick to review (can't add him to reviewers without him joining this github org first - invite sent).