go-bitsong icon indicating copy to clipboard operation
go-bitsong copied to clipboard

NFT structure

Open giorgionocera opened this issue 3 years ago • 2 comments

Here I'm posting some reasonings about the structure of the object for the nft module. By points:

  1. Why do we use the coll_id (Collection ID) inside the Metadata structure? Is it a matter of linking the metadata to the collection to generate a sort of versioning of the metadata for a collection?
  2. What about separating the MetadataID from the collectionID? I mean, could it be better to use a global ID counter for the MetadataID instead of having a list of metadataID for each collection? This also causes the need for a last_metadata_ids array.
  3. What about using the update_authority (same for metadata_authority) field to see if a collection (same for metadata) is mutable or not? In the fantoken module, the authority address is used such that if it is empty, the asset cannot be modified anymore. What about using the same pattern here too? Is it possible, and moreover, is it a good choice?
  4. What about using the minter naming instead of mintAuthority and authority instead of metadata_authority or update_authority? It would match the same naming used on the fantoken module.
  5. Why do we choose to use CollID, MetadataID and Seq in the NFT ID, which in this case are three integers?
  6. Since the metadata contains the collectionID, which is the sense of repeating the collectionID on the NFT too?

giorgionocera avatar Sep 28 '22 13:09 giorgionocera

  1. We use collection id on metadata to start metadata id from 1 per collection. If metadata id is used globally, collection creators won't know that what their metadata ids will be for their collections.
  2. Originally, it used to use global metadata id, but for the reason 1, global metadata id is converted to local metadata id per collection.
  3. metadata could be updated while it's in auction, and that's why mint authority and update authority has been seprated
  4. I think it make sense to change the term to minter and authority

ryusmo avatar Sep 28 '22 17:09 ryusmo

  1. Why this (namely "[...]collection creators won't know that what their metadata ids will be for their collections.") should be a problem? We could query Metadata by Authority for example. What do you think?
  2. Sorry, I was not clear enough in the explanation. I was meaning: What about using only the update_authority field to see if a collection is mutable or not, instead of also using the is_mutable attribute? We could set the update_authority to an empty address to disable the mutability. You can see an example of implementation in the fantoken module (here there is a short to the docs, where you can find a slightly different explanation) What do you think about it?
  3. Nice! 💪

giorgionocera avatar Sep 29 '22 07:09 giorgionocera