IMPROVEMENT: NFT Metadata

[joshuahannan]

Issue To Be Solved

NFTs always have some sort of metadata associated with them. Historically, most of that metadata has been stored off-chain, but we would like to create a standard for metadata that allows all metadata to be stored on-chain so everything about the NFTs is truly decentralized.

This issue is meant for discussion about the possibilities of the solution. More documentation and examples will be added as we research and discuss more.

I am currently leading the charge on this, but I have a lot on my plate and don't know if I can give this issue the love it deserves, so if someone from the community wants to lead, I would love to speak with you!

Suggest A Solution

• Ideally, we'd like to try to have some sort of self-describing json format for the metadata, but more research needs to be done on how we could support this in Cadence and the flow sdk.

Context

The Avastars project is an interesting project on Ethereum that that we could potentially take inspiration from for our metadata.

[MiyaSteven]

I can solve this problem if you have the patience to walk me through some basic knowledge necessary to understand what all the moving parts are.
Questions I have:

1. Why has the metadata associated with NFT's always been stored off-chain?
2. What are current blockers that create this issue?
3. In a perfect system where everything was possible, how would the metadata of an NFT be stored?
4. Is it possible for a User to store their own metadata for their owned NFTs? Why or why not?
5. What has worked so far in existing projects that has moved us closer to solving this issue and where did they leave off and why could they not completely accomplish this?
   If you answer these, my next response might also be a wave of questions since I am pretty new to understanding data flow/storage, but my problem solving skills in general are solid as long as I understand the entire picture/pieces. Cheers, WK

[joshuahannan]

@MiyaSteven Sorry for the late response. I can answer a few of your questions, but I'll need to find some more help answering some other ones, as I am not super familiar with the state of metadata storage in other blockchains

1. Metadata associated with NFTs has been stored off-chain because on chain storage is usually expensive and hard to manage. Gas fees for storing on ethereum were high so the common recommendation was to only store the things that absolutely needed to be stored. Also, Solidity didn't provide built in libraries to manage images, videos, json, and other complex file types so apps decided to just keep most of this in their own off-chain database
2. Similar to my last answer, the main blockers are that Cadence does not provide an easy way to manage json and other complex files, so we need to either build it into to the core of the language, or we need to write functions in our smart contracts to manage these.
3. This is a hard question to answer, but I think the consensus would be to have a customizable standard for storing self-describing json files in resources that can hold almost any type of metadata, such as numbers, text, images, videos. The contract would be able to parse some of these and return their values to the caller.
4. It is definitely possible to store the metadata for an NFT in the NFT itself, because you could just add a field or fields to the NFT that holds the metadata in an encoded format.
5. Other projects on Ethereum have been trying to solve this issue and are seeing decent success. Some examples I know of are Avastars and Chainfaces so I would recommend checking those out.

Thanks for reaching out and feel free to ask more questions if you still need help!

[pizzarob]

I'm of the opinion that metadata should be flexible and scalable. You don't get any of those things with current on-chain ethereum solutions.

Metadata should be flexible
As a creator of an NFT I should be able to update the metadata as I see fit to support my project without having to rewrite my smart contract to change the shape of my data, or submit a transaction to update the data.

Metadata should be scalable
This ties into flexibility as well, but metadata needs to be scalable. As NFTs become more mainstream and projects become larger not only does metadata need to be flexible and upgradeable, but this flexibility needs to scale. If my project has 10 million NFTs it doesn't make financial sense to have to update 10million NFTs on chain (my experience is on Ethereum).

My platforms solution for this is to use a traditional storage space and have a server that dynamically retrieves metadata based on the contract address and token ID. This allows for metadata to be updated at scale to provide flexibility for enterprise projects.

If this storage space was decentralized and there could be a history of metadata updates I think that would suffice. Updating metadata needs to be cheap, fast and easy.

[bjartek]

Could a start to this be to support labels that are pure {String,String} Dictionary and expose that in the public interface and collection interface. Just doing that would make it a lot easier to experiment with.

Metadata should have a schema that could be migrated

Adding support for migrating the data in the schema to a new format would be a very nice feature here. A binary format like avro supports this. There are lots of examples on how people use it in kafka to allow sending messages that are backwards compatible with old formats.

What is the size of a flow block gonna be? Will it be feasible to store a pretty large SVG on-chain.

[joshuahannan]

We originally had a {String: String} dictionary in the NFT standard, but we felt that is wasn't necessary since we wanted the standard to be pretty minimal and didn't want to force a relatively weak standard for metadata on the users of the standard. But you can experiment with that in your own contracts that implement the NFT standard. That is similar to what top shot does.

Yes, I totally agree that the schema should be able to be migrated. We are discussing a process for how contracts are stored and upgraded in accounts in onflow/cadence#221 (comment), which includes a part about how data from contracts is migrated to the new version. We'd love some feedback or ideas if you have any.

We aren't totally clear on what the size of a flow block will be but I feel fairly confident that you'll be able to store larger files like that as long as you have the money to pay for storage.

[bjartek]

Another thing me and @psiemens talked about yesterday was implicit support for something like IPVS.

When sending a transaction with an specific type that field is not sent on chain but sent into IPVS, and if the field is accessed it is pullef from there. Or something like that.

[ericelliott]

1. Why has the metadata associated with NFT's always been stored off-chain?

Cost per GB of storage on Ethereum is measured in the millions of dollars. For comparison, price per GB of storage on cloud services like AWS is $0.05/month. Storage architecture must be radically different on Flow to make this idea even remotely cost-effective. Currently, it's not so hard to fire up an IPFS pinning service, and store only the hash on-chain (which is a URL in IPFS-land).

2. What are current blockers that create this issue?

I don't know the Flow architecture well enough to answer this question.

3. In a perfect system where everything was possible, how would the metadata of an NFT be stored?

Different NFTs can represent radically different information, needing radically different data structures. There is no one-size-fits-all solution for NFT data representation.

4. Is it possible for a User to store their own metadata for their owned NFTs? Why or why not?

That would effectively shard Flow storage. How would you achieve consensus on data representation?

5. What has worked so far in existing projects that has moved us closer to solving this issue and where did they leave off and why could they not completely accomplish this?

Store real data on IPFS. Encode only the hash on the blockchain. The primary blocker for this on Ethereum is the cost of storing data on Ethereum ($millions/GB).

[cybercent]

An idea would be to use bson (http://bsonspec.org) , and store metadata on chain.

Edit:
Instead of imposing a predefined schema, we would let the schema to be decided by the developer but add a easy way to filter items (NFTs) in a collection based on the fields the metadata would contain.

1. The NFT standard would have a metadata field of type bson.
2. Cadence would provide methods to filter items in a collection based on metadata.

Reference for querying bson data in Postgres
https://www.postgresql.org/docs/9.6/datatype-json.html

Example:

metadata = {
 "firstName": "Kevin",
 "lastName": "Durant",
  "season": 2019,
  "team": {
       "name": "Nets", 
       "primary_position": "Small forward"
   }
}

Query examples

Filter by presence of a key.
metadata ? "firstName"
Response: all items in the collection that have the key firstName set.

metadata ?| ["firstName", "season"]
Response: all items in the collection that have one of the keys firstName OR season set. Hence the |.

metadata ?& ["firstName", "season"]
Response: all items in the collection that have both keys firstName ANDseason set. Hence the &.

Filer by checking inclusion of one JSON into another one.
metadata -> team @> {"name": "Nets"}
Response: all items in the collection that have the team name set to Nets.

metadata -> team @> {"name": "Nets", "primary_position": "Small forward"}
Response: all items in the collection that have the team name set to Nets and the team position set to Small forward

Field names
If needed, the on-chain metadata could have short names for keys to save on storage.
The developer could make available the desired mapping on his website. The mapping would be used by other dapps and wallets that want to interact with NFTs created by the developer and need to display that info to the end user.

<head>
<meta name="flow-0x01.NBATopShot" content="https://my-dapp.com/0x01.NBATopShot.json">
</head>

0x01.NBATopShot.json could look like this:

"en": {
 "firstName": "Player First Name",
 "lastName": "Player Last Name",
  "season": "NBA Season",
  "team": {
       "name": "Team Name", 
       "primary_position": "Player primary postion"
   }
}

[alxocity]

Not sure if there should be a metadata standard. Perhaps just a metadata field that is a custom Metadata resource per NFT. Then any client can traverse this resource to get relavent metadata. The contract can also define a metadata template field for recommendations on displaying the data using handlebars or similar; although, these metadata display templates are probably better suited as scripts rather than contract functions.

Tldr; seems metadata can be stored however the dev wants, but have a standard for the metadata script used to read and format the data.

[alxocity]

And building standards for all complex data types will be beneficial. Although, you can jam almost anything into a string ;)

[ericelliott]

Many schemas that may be suitable for NFTs have already been defined and are available at schema.org including images, video, audio, and so on.

ERC-721 specifies a simple metadata schema that looks like this:

{
    "title": "Asset Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this NFT represents",
        },
        "description": {
            "type": "string",
            "description": "Describes the asset to which this NFT represents",
        },
        "image": {
            "type": "string",
            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",
        }
    }
}

ERC-721 tokens get associated with their metadata on-chain using a tokenURI field in the token contract. Further information such as description and image are parsed from the corresponding JSON record referenced by URI. (See above). That URI generally references a JSON document and assets on IPFS.

Open questions:

• How expensive is it to host data per GB on Flow? (Please show your work on calculating this - e.g., Write a script that will check storage costs with current blockchain data and show how we can estimate those costs into the future as the Flow blockchain grows).
• How do current applications such as NBA Top Shot associate Flow NFTs with the creative assets associated with them?
• Should there be a metadata table to associate metadata with NFTs (so we can make many-to-one relationships?)
• Should metadata be stored on something like IPFS instead of on-chain (so we can separately optimize for data storage use-cases)?
• Is it better to bring storage in-house into the Flow blockchain ecosystem and standardize so we can have more control over concerns such as deletion/shredding capabilities and performance characteristics?
• How do we address data stored on Flow? (IPFS multihash addresses may be good prior art to build on here) - same data always points to same multi-hash, which can simultaneously prevent data duplication on the blockchain and prevent/discover unauthorized use of IP.
• If it is discovered that a bad (or naive) actor violated IP rights and uploaded proprietary or confidential information, how can you erase/scrub/shred data that's already stored on the blockchain? (It should not be possible to permadox a user by recording legally protected, personally identifying information to a blokchain). Can we use some sort of strong encryption/data sharding, and shred the keys if the consensus is that somebody acted in bad faith when they added the data to the blockchain in the first place?

[pizzarob]

Using standard schemas for different types of assets from schema and specifying these from the start is a great idea. Case in point - the ERC-721 spec on Ethereum has a limited metadata schema definition and now different platforms have different metadata shapes for different media types which ruins the off-the-shelf interoperability between these platforms.