-
Notifications
You must be signed in to change notification settings - Fork 84
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
SIP-016 Metadata for Tokens #44
Conversation
I am looking for more real world examples like: {
"collection": "PoX Monks",
"id": 1,
"name": "PoX Monk 1",
"image": "ipfs://ipfs/QmegB9FURt6Jz1kGbaQxNqhvoPk9G2b87rxUE1h9DLDbDF/PoX%20Monk%201.jpg",
"attributes": [
{
"type": "body",
"value": "buff monk"
},
{
"type": "headwear",
"value": "orange hat"
}
]
} Here we see additional properties: "collection" and "id", also "type" instead of "trait_type". |
The SIP contains a JSON schema definition written in JSON. {"title": "EVERYDAYS: THE FIRST 5000 DAYS",
"name": "EVERYDAYS: THE FIRST 5000 DAYS",
"type": "object",
"imageUrl": "https://ipfsgateway.makersplace.com/ipfs/QmZ15eQX8FPjfrtdX3QYbrhZxJpbLpvDpsgb2p3VEH8Bqq",
"description": "I made a picture from start to finish every single day from May 1st, 2007 - January 7th, 2021. This is every motherfucking one of those pictures.", "attributes": [{"trait_type": "Creator", "value": "beeple"}],
"properties":
{"name": {"type": "string", "description": "EVERYDAYS: THE FIRST 5000 DAYS"},
"description": {"type": "string", "description": "I made a picture from start to finish every single day from May 1st, 2007 - January 7th, 2021. This is every motherfucking one of those pictures."},
"preview_media_file": {"type": "string", "description": "https://ipfsgateway.makersplace.com/ipfs/QmZ15eQX8FPjfrtdX3QYbrhZxJpbLpvDpsgb2p3VEH8Bqq"},
"preview_media_file_type": {"type": "string", "description": "jpg"}, "created_at": {"type": "datetime", "description": "2021-02-16T00:07:31.674688+00:00"}, "total_supply": {"type": "int", "description": 1},
"digital_media_signature_type": {"type": "string", "description": "SHA-256"},
"digital_media_signature": {"type": "string", "description": "6314b55cc6ff34f67a18e1ccc977234b803f7a5497b94f1f994ac9d1b896a017"},
"raw_media_file": {"type": "string", "description": "https://ipfsgateway.makersplace.com/ipfs/QmXkxpwAHCtDXbbZHUwqtFucG1RMS6T87vi1CdvadfL7qA"}}} |
Example with extensive use of properties. Here trait definitions (that can be defined in attributes) and properties are mixed into the "properties" value. {
"name": "foo",
"image": "bar",
"properties": {
"making_of_video": {
"display_type": "uri",
"trait_type": "string",
"value": "protocol://identifier"
},
"video_md": {
"display_type": "none",
"trait_type": "xml", // string???
"value": " <xs:element name="VIDEOMD" type="videoType"/>
<xs:element name="VIDEOSRC" type="videoType"/>
<xs:annotation>
<xs:documentation>VIDEOMD: LC-AV Video Metadata Extension Schema. VIDEOMD contains technical ...
</xs:documentation>
</xs:annotation>
<xs:complexType name="videoType">
<xs:annotation>
<xs:documentation>A complexType for encapsulating and organizing within a singleparent element ...
</xs:documentation>
</xs:annotation>
..."
},
} |
Hoi Axopoa here. For most of the NFT collections where the "source" is "hosted", a format like this would (maybe) be ok. {
"name": "PoX Monks",
"description": "A unique collection of monks",
"author": "Monks Studio",
"version": 1,
"date": 1631645313396,
"items": [
{
"id": 1,
"name": "PoX Monk 1",
"source": "ipfs://ipfs/QmegB9FURt6Jz1kGbaQxNqhvoPk9G2b87rxUE1h9DLDbDF/PoX%20Monk%201.jpg",
"attributes": [
{
"type": "body",
"value": "buff monk"
},
{
"type": "headwear",
"value": "orange hat"
}
]
},
{
"id": 2,
"name": "PoX Monk 2",
"source": "ipfs://ipfs/QmegB9FURt6Jz1kGbaQxNqhvoPk9G2b87rxUE1h9DLDbDF/PoX%20Monk%201.jpg",
"attributes": [
{
"type": "body",
"value": "slim monk"
},
{
"type": "headwear",
"value": "blue hat"
}
]
}
]
} Edit: Seems like I miss a lot of information. I will do my homework and come back |
For new collections, stxnft.com goes with a format that looks something like this:
This is similar to the OpenSea metadata format, with the addition of the additional field This is because right now SIP-009 doesn't support "collection-level" metadata ( To me, the OpenSea metadata format works just fine with this collection-level metadata caveat. I'd support either (a) an extension to SIP-009 allowing for NFT contracts to return a name and symbol (e.g., |
Which properties should be required? |
@MarvinJanssen This SIP tries to specifies metadata for any type of tokens. It should be applicable also for SIP-013 tokens (#42). Does it make sense? |
@Jamil I support b). I propose field "properties.collection". |
Thanks @friedger this is great. I think bringing in lots of real world examples makes sense (like you have been doing). We should tap into our friends in the EVM space and see what they are doing these days too. As long as there is a version field, mentioned in #42, then I think we can come up with anything. |
On stxnft.com right now we'll render any metadata as long as However, are we going to require tokens which represent non-image data (e.g., It'd certainly make things easier on my side but I'm not sure people will follow that for non-image NFTs. |
This sip is mainly about sip compatible contracts, not about native assets, like bns. BNS needs a wrapper! It would be great to specify an algorithm to display tokens without image like identicon. Non-image NFTs would still need some kind of image to represent on a marketplace assuming users use the marketplace with their eyes. We need to think about accessibility! |
The specification for metadata should apply to individual NFTs ... for collection data, that should be included in attributes. ie. a "collection" is not an nft. Ie for Boom NFTs the metadata would look something like this below.
Further I suggest:
|
@dantrevino properties and attributes should be swapped, shouldn't it? At least that is how opensea defines it: https://docs.opensea.io/docs/metadata-standards#metadata-structure attributes consists of trait_type, display_type and value. properties can be anything. |
yup got that backwards |
@jcnelson The schema has been validated using JsonValidator. See https://github.com/Light-Labs/media-metadata-schemas |
Just checking in. Is there a mainnet contract using this trait yet? |
@friedger Feel free to advance the status of this SIP to |
Hi all just wanna make sure this is captured officially. During last Friday's weekly SIP call #79 (comment) I raised this point. According to the activation criteria: We are now at bitcoin block 749,565. So I'm now working with the NFT marketplaces to fetch data to confirm 10 contracts have been deployed already. |
There's a miss here @friedger ... this is not a contract sip, its a metadata sip. @Hero-Gamer there is no way to look at a contract and determine if the metadata supports sip-016. The contract only has a link to metadata, but, for instance, the boom-300 "contract" was deployed 10 months ago, before the sip was complete, and initially we created nfts that were not sip-016 compliant. However, now it is deploying nfts that are sip-016 compliant. Same contract. https://explorer.stacks.co/txid/SP1QK1AZ24R132C0D84EEQ8Y2JDHARDR58R72E1ZW.boom-nft-300?chain=mainnet both minted from the same contract: |
Our Create Portal contracts are almost SIP-16 compliant but not quite, since we don't have the required "sip" field in the JSON. Working with our developers to add that for all future contracts, but not sure 10 contracts like this will be deployed by Wednesday. What is the process if this SIP does not meet the requirements by then, and we have to re-start? |
I found these with
|
Technically yes, you would need to restart in general since it indicates that the SIP doesn't have enough interest. But it seems that in this specific case, the only reason this SIP hasn't activated was due to a bug in the implementation (e.g. a missing So yeah, go ahead and change the block height and keep everything else as-is. |
Here is another one: https://explorer.stacks.co/txid/SP1QK1AZ24R132C0D84EEQ8Y2JDHARDR58R72E1ZW.boom-nft-300?chain=mainnet Makes it 8. |
No. 9 - a new one deployed a few hours ago: |
153 bitcoin block time left, approx. 1 day. (current block time 749,847) |
The contract above ( The next contract deployed with the Gamma Portal will be the 10th :) |
No. 10? This NFT has a dynamic metadata. The latest mint has a SIP-016 metadata, prior mints were not.
Latest mint with
Earlier mint example without
|
If all contracts checks out: |
Awesome to see! I will take a look as soon as I am able, and if it all checks out, it will be my pleasure and honor to advance this to Ratified 🎉 |
@friedger I'm not sure where to look for the metadata URL here? This appears to be a contract deploy from 6 months ago. The rest look good to me. |
Perhaps Xan Ditkoff can help. :)
|
@dartman10 thanks! Looks good to me. It is my pleasure to inform everyone that this SIP has met all of the criteria for ratification! Please transition this SIP to "Ratified" and I'll merge it 🎉 |
Great work everybody! @jcnelson I changed the status to Ratified. Anything else to do? |
Nope; going to merge |
This PR