Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: metadata standard or best practices for animated and non-image filetypes #192

Open
sk33z3r opened this issue Mar 9, 2022 · 3 comments

Comments

@sk33z3r
Copy link

sk33z3r commented Mar 9, 2022

I understand there is no standard for metadata files yet. However, OpenSea is making strides to develop one, and I think that it would be beneficial to come up with something for a few reasons. At the very least, some type of article to the users about how metadata is structured in various ways in the NFT world. Basically something to make the user consider a future market place when minting something other than a static image.

Notes:

  • Users currently are minting freely almost any filetype. However, everyone is putting their file into the "image" field, even if it is not an image. Some users are confused by why their NFT may not show up in the explorer if it is, say, an MP4 file. It's not clear to them that the logic on the backend to pick and choose display methods may never come.
  • There is no clear indication of what the best practice is from loopring for animated and non-image filetypes, so I fear that when a marketplace comes it will render those NFTs more or less incompatible with the marketplace, because their file is inside what is effectively a thumbnail field.
  • Many platforms use a "multimedia_file" or similar field in addition to the "image" field. This way, the UIs will default to showing a thumbnail specified under "image", and then perhaps a button to "View" or "Download" multimedia that points to the value at "multimedia_file". See below.

The OpenSea standard documentation

image

@sk33z3r sk33z3r changed the title Request: metadata standard for viewing NFTs in the wallet Request: metadata standard or best practices for animated and non-image filetypes Mar 9, 2022
@sk33z3r
Copy link
Author

sk33z3r commented Mar 10, 2022

For anyone that comes to this ticket looking for an idea of how metadata should be structured, you may want to follow the below. There have been an influx of high-quality NFTs minted, all following this same schema.

The Bare Minimum

At the very least, it would be a good idea to include these fields. Note that the "image" field is intended to be a smaller, faster loading thumbnail of your content, while the "animation_url" is intended to be the full size, video, or other file type of your NFT. It's OK to set both to the same value, several NFTs have done it this way.

{
    "name": "NFT Name",
    "description": "Description of your collection.",
    "image": "ipfs://CID-TO-SMALL-THUMBNAIL",
    "animation_url": "ipfs://CID-TO-FULL-SIZE-IMAGE-OR-VID",
    "royalty_percentage": 0,
    "attributes": [],
    "properties": {}
}

Royalties

The royalty_percentage field is an integer. So far we've seen anywhere between 0 - 10 in actual mints. In the Smart Contract, there is also a creatorFeeBips field. So far all of the royalty_percentage fields have matched the creatorFeeBips set in the smart contract.

According to documentation and testing, the maximum value accepted for creatorFeeBips is 50.

Example with Traits

With traits you can give some indication of rarity. This is just an example. It's unlear what "properties" is exactly, but they are identical to the traits in the cases that I have seen so far. They are both slightly different data types, so could just be different ways to store the same data for various purposes on the front-end.

{
    "name": "NFT Name",
    "description": "Description of your NFT",
    "image": "ipfs://CID-TO-THUMBNAIL-SIZE",
    "animation_url": "ipfs://CID-TO-FULL-SIZE-OR-FILE",
    "royalty_percentage": 0,
    "attributes": [{
        "trait_type": "Hair",
        "value": "Curly"
    }, {
        "trait_type": "Nose",
        "value": "Massive"
    }, {
        "trait_type": "Mouth",
        "value": "Closed"
    }, {
        "trait_type": "Chin",
        "value": "Beard"
    }],
    "properties": {
        "Hair": "Curly",
        "Nose": "Massive",
        "Mouth": "Closed",
        "Chin": "Beard"
    }
}

@sk33z3r
Copy link
Author

sk33z3r commented Mar 12, 2022

I created a site to generate this metadata in large batches should anyone want to try it out: https://metagen.sk33z3r.site

@OctagonNFT
Copy link

Hi,

MIME types could be passed along with all of the content.

A game asset with multiple media elements might look like this:

{
	"name" : "Title of NFT"
	"description" : "",
	"royalty_percentage": 1,

	"external_url" : "https://creators.site/",


	"image" : "ipfs://CID-TO-SMALL-THUMBNAIL",
	"image_type" : "image/png",

	"animation_url" : "ipfs://CID-TO-FULL-SIZE-IMAGE-OR-VID",
	"animation_type" : "video/mp4",


	"attributes" : [
		{
			"trait_type" : "Author",
			"value" : "OctagonNFT"
		},
		{
			"trait_type" : "Type",
			"value" : "Collection of multiple data types"
		}
	],
	"properties": { },

	"content" : [
		{
			"name" : "A cool picture",
			"content_type" : "image/webp",
			"image" : "ipfs://...",
		}
		{
			"name" : "An embedded image",
			"content_type" : "image/png",
			"image_data" : "data:image/png;base64,...",
		}
		{
			"name" : "3Dmodel_1",
			"content_type" : "model/fbx",
			"FBXHeaderExtension" :  {}
			"GlobalSettings" :  {}
			"Documents" :  {}
			"References" :  {}
			"Definitions" :  {}
			"Objects" :  {}
			"Connections" :  {}
			"Takes" :  {}
		},
		{
			"name" : "runtime_settings",
			"content_type" : "application/specific",
			"data" : "...",
		}
	]
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants