pub struct ContractMetadata { .. } → rename to NFTContractMetadata to match the standard.
Remove gate_url from Collectible. Full URL can be constructed by concatenating NFTContractMetadata.base_uri and gate_id value, and it is task for consumer. We assume that all Collectibles share same base_uri as they are stored in one contract.
pub struct Collectible {
pub gate_url: String,
}
Remove sender_id. If absolutely needed, Indexer has this in transaction history.
Make copies U16 — agreed that 65535 copies would be enpugh
Mandatory Metadata attributes and length to be checked: Title (140), Copies {1...U16}, Media {1K max}
Reconstruct TokenMetadata. Now we have created_at & modified_at attributes in Toklen struct, but they are against the standard. TokenMetadata struct that will be injected into Token struct, but it also has attributes of the same meaning, but named differently. However, in our case TokenMetadata struct represents Collectible, so issued_at and updated_at will hold timestamps when Collectible was created (that makes sense, because we want to certify when Creator instantiated his/hers Collectible on-chain). But it will be confusing when TokenMetadata gets attached to the Token struct. One option I am thinking about is to overwrite data in TokenMetadata struct: created_at → issued_at, modified_at → updated_at, and not expose created_at & modified_at when Token struct is returned not to get anyone confused. Just thinking what happens to our Token if it gets to 3rd party marketplace one day (not owned by Mintgate) and thus relying on standard? Such marketplace would assume that Metadata fully belongs to Token itself.
pub struct Token {
pub gate_id: GateId,
/// Represents when this `Token` was minted, in nanoseconds.
/// Once this `Token` is minted, this field remains unchanged.
pub created_at: u64,
/// Represents when this `Token` was last modified, in nanoseconds.
/// Either when created or transferred.
pub modified_at: u64,
/// If this `Token` was transferred, this field holds the previous owner.
/// Otherwise is empty.
pub sender_id: AccountId,
**+ metadata: CollectibleMetadata,**
}
Change nft_token method to return Token Struct with Metadata from relevant Collectible, adjusted as described above.
Add pub fn nft_token_uri(TokenID) view method to return full URL of related Collectible, as {NFTMetadata.base_uri}+{Token.Gate_Id} - needed because we do not have any shortcut to map any token to its web origin quickly. Only available alternative now is to read nft_metadata(), then read nft_token() and then perform data extraction on the client. nft_token_uri will be standard method to be implemented by contract exactly for such cases.
pub struct ContractMetadata { .. }
→ rename toNFTContractMetadata
to match the standard.Remove
gate_url
fromCollectible
. Full URL can be constructed by concatenatingNFTContractMetadata.base_uri
andgate_id
value, and it is task for consumer. We assume that all Collectibles share samebase_uri
as they are stored in one contract.Remove
sender_id
. If absolutely needed, Indexer has this in transaction history.Make
copies
U16 — agreed that 65535 copies would be enpughMandatory Metadata attributes and length to be checked:
Title (140)
,Copies {1...U16}
,Media
{1K max}Reconstruct
TokenMetadata
. Now we havecreated_at
&modified_at
attributes in Toklen struct, but they are against the standard.TokenMetadata
struct that will be injected intoToken
struct, but it also has attributes of the same meaning, but named differently. However, in our caseTokenMetadata
struct representsCollectible
, soissued_at
andupdated_at
will hold timestamps whenCollectible
was created (that makes sense, because we want to certify when Creator instantiated his/hers Collectible on-chain). But it will be confusing whenTokenMetadata
gets attached to the Token struct. One option I am thinking about is to overwrite data inTokenMetadata
struct:created_at
→issued_at
,modified_at
→updated_at
, and not exposecreated_at
&modified_at
whenToken
struct is returned not to get anyone confused. Just thinking what happens to our Token if it gets to 3rd party marketplace one day (not owned by Mintgate) and thus relying on standard? Such marketplace would assume that Metadata fully belongs to Token itself.Change
nft_token
method to return Token Struct with Metadata from relevant Collectible, adjusted as described above.Add
pub fn nft_token_uri(TokenID)
view method to return full URL of related Collectible, as{NFTMetadata.base_uri}+{Token.Gate_Id}
- needed because we do not have any shortcut to map any token to its web origin quickly. Only available alternative now is to read nft_metadata(), then read nft_token() and then perform data extraction on the client.nft_token_uri
will be standard method to be implemented by contract exactly for such cases.