New Standard: NFT metadata - Milestone 1

[figs999]

Description

This PR is for issue #16

This PR fulfils Milestone 1 Requirement:
"Define a rough outline of your proposal. This can be a written document (i.e. a GitHub issue), but should also include Cadence code snippets that illustrate the core concepts of the standard."

• NFT Metadata Schema has been reduced to an updateable tag system, which allows NFTs to conform to multiple schemas and add conformance to new schemas as standards evolve over time.
• Immutable and Mutable metadata are both supported in this implementation
• Mutable metadata will utilize Capabilities to maintain pointers to external data, which allows multiple resources to point to the same large binary data (upload once for all that share that metadata)
• Usage of Capabilities in Mutable metadata elements allows the metadata data to be stored in the same account or in the developers account, allowing devs the flexibility of subsidizing storage costs.

Submission Links & Documents

NA

Requirements Check

• Have have you met the milestone requirements? YES
• Have you included tests (if applicable)? NA
• Have you met the contribution guidelines of the repos you have submitted code to (if applicable)? YES

Other Details

• Is there anything specific you'd like the PoC to know or review for?
  Please review "Milestone 1/NFTStandard.cdc", comments describe functionality and intended usage.
• Are there other references, documentation, or relevant artificats to mention for this PR (ie. external links to justify design decisions, etc.)?
  The NFT Metadata discussion thread
  The primary concerns that contributors have brought up are the competing needs for a flexible but parsable schema,
  immutable and mutable metadata, and storage cost minimization.

[figs999]

I have pushed Milestone 2 into the PR.

[rheaplex]

In the Cadence code that Dapper has written, we tend to use descriptive names that provide context and/or indicate intent, rather than well-known prefixes/suffixes. We describe the scope, constraint, or affordance provided by Capability interfaces, e.g. CollectionPublic, Provider, Receiver. And for concrete types we tend to emphasize what they are or what they do, e.g. NonFungibleToken, FlowEpoch, NodeDelegator.

None of this is a criticism of other approaches to naming, or to the specific naming used here - which is very clear, regular, and logical, all of which is of advantage when reading a codebase. I would however imagine that we will be looking for naming that reads similarly to the existing standard and core contracts, and this may be worth considering.

[figs999]

Gotcha. I will consider renaming. This is the first thing I've ever written in Cadence, so I am not very familiar with the standards as of yet.

[rheaplex]

Note that the content of this array can be manipulated by the owner of the MetaData struct, and functions called on value types within it (and on types in arrays/dictionaries within those, and so on recursively...).

I usually recommend using access(self) for the metadata stored in an object, and returning (an implicitly lazy copy of) it with a pub` accessor.

i.e.:

access(self) let elements: [MetaDataElement]

pub fun getElements(): [MetaDataElement] {
  return self.elements
}

This applies to all the types below that expose a dictionary or array as a pub member variable.

[figs999]

Thanks! I had gone through looking for that issue and changed a few others, but missed that one!

[psiemens]

Approved for milestone 1! Thanks for writing up the Cadence code, @figs999.

However, before we merge, can you update this PR to be only milestone 1 files? We'll review milestone 2 separately.

[figs999]

Approved for milestone 1! Thanks for writing up the Cadence code, @figs999.

However, before we merge, can you update this PR to be only milestone 1 files? We'll review milestone 2 separately.

Done!

[psiemens]

Approving and merging! @figs999