Ahh this is good to know, thank you!
Under the following propposal (CIPs/CIP-NFTMetadataStandard.md at ed48e5a38b75eb31f16288338a3c1ef93fecde47 · cardano-foundation/CIPs · GitHub)
{
"721": {
"<policy_id>": {
"<asset_name>": {
"name": "<name>",
"image": "<uri>"
}
}
}
}
- Why is image marked as required? Not all NFT are images. Could be an audio, text, video or a file.
- Most NFTs on the web use IPFS to host their tokens, and most of the people that use IPFS, separate the
<uri>intohostameandpath. E.g.
{
"host": "www.website.com",
"path": "/path/to/my/nft"
}
This is helpful to avoid hitting the limit of 64 bytes per string limit.
1 Like
Totally agree, it was noted but for some reason they think there should always be a thumbnail or something at a minimum. The back and forth is in the link bwbush noted above.
There are a couple areas like that I’m not fully agreeing with. For example the token registry seems unnecessary. Use your metadata wisely and it should act as the registry, it feels extremely redundant. Hopefully someone can help me understand that.
Agree.
Yes, maybe having to require a thumbnail is a good idea, but…
To make a thumbnail you have to process the original file with some algorithm, E.g. if it’s an audio maybe you create a wave pattern of the file, if it’s a video maybe you select a frame or make a .gif file of certain frames.
And like all files, you have two options to keep the file forever:
- Either you upload the Thumbnail to IPFS
- Or you host it on a server
If you host it on a server, then you have to make sure the url stays valid for the eternity of time, which this is very hard to mantain.
Uploading it to IPFS could sound like the solution, but there’s a catch, and a very problematic one…
To make the thumbnail from the original file, maybe you used a library to produce the wave pattern image or to make the .gif, and we all know that encoder/algorithms that produce this kind of stuff keep evolving and changing. So maybe next time that you want to populate the IPFS with this NFT thumbnail, the resulted thumbnail has some bytes of difference and now the IPFS hash turns to be different. And now you have an invalid thumbnail and impossible to re-make embedded on the chain forever 
.
Maybe solution for this IPFS problem is to ask the author to make the Thumbnail on their own for the NFT… instead of auto-generating it with some service, but now you have to keep 2 original files forever, which doesn’t sound bad, but yeah, more responsibilities.
1 Like
Yeah I think you have good points. Many of these fields should be optional. For a musical album for example maybe you just need one thumbnail for the whole thing, but each track is an NFT with it’s own metadata. Why add redundant data to everything when a parent asset can provide for it? There are constructs we need to allow for by keeping the standard loose especially in the beginning.
1 Like
This is quite excellent discussion.
Convenience, consistency, and familiarity seem to be the primary motivations cited. If metadata is merely “data about data” then I would caution that there are infinite use cases for what metadata can convey. We could theorize about the use cases and never even begin to exhaust the imagination.
A standard for metadata or even specifically NFT metadata should be generic. Properties such as ID, name, schema, version, etc are more universal. Properties such as image, URI, copyright, color, etc are far too specific.
Enforcing any standard always requires acceptance and adherence by the community that would use them. However popularity is not a good enough metric as that tends to create a momentum that repeats a pattern due to the existence rather than the correctness.
I think we would first need to consider some sort of functionary group like ISO, RFC, IEEE, etc that would allow the community to draft, review, ratify, reject, and modify any standard proposed in a way that would allows us to avoid the mistakes of the past and improve upon the mistakes we make now in the future.
Edit: Yes, I am aware that is part of what CIP is for. I meant perhaps making a CIP for how to propose transaction data standards first 
Adding a note here - there was a brief mention of this CIP at the end of this week’s CIP Editor Meeting #21 around 32 mins.
This tentative NFT CIP will be discussed more in depth in two weeks for CIP Editors meeting #22 - The time is a bit difficult for US Timezones but recording and notes are available.
There are extended discussions about what the continued NFT Standards should be - CIP Editors and engaged community members continue to touch to this in our last CIP Editor Meeting #22 - and invite you to check out meeting notes if of interest.
There is another conversation scheduled for Meeting #23 on Crowcast next Tuesday - do register and attend if you are able to!
2 Likes
Check out IPNS for data that needs to change while requiring a static link … it’s not elegant either but as yet no solution is.
1 Like
Hello guys, I got a problem and I dont know how to solve it.
I want to create an NFT, and when you click on the image on sites like pool.pm for example, you got re-directed to my site, not to the ipfs.blockfrost…
I usually use this metadata:
{
"721": {
"<Policy_id>": {
"<asset_name>":{
"name": "<name>",
"image":"ipfs://<Hash>",
}
}
}
}
but I dont know what should I put on the metadata to redirect to my site.
NFTs like Cardanobit, Spacebudz and other brands have this option.
Thanks guys!!!
If the website is following the Ethereum NFT standard as denoted by the “magic number” 721 then it seems that may have bled into other ecosystems due to network effect alone.
I would still hope Cardano would adopt a meta data standard based on the multi-asset ledger that is part of its protocol. This of course could include compatibility with ERC-721 and other formats for portability. Using another chains standards and incorporating their design and limitations verbatim would be unfortunate.
In any case for your question I picked a few NFT at random from pool.pm and the following were popular keys for a website link in addition to the image URI.
“site”
“homepage”
“twitter”
“webpage”
etc
It you want to copy someone else’s format like the projects you mentioned simply lookup the asset hash of the NFT on cardano scan and trace back to the minting transaction. This will show you the exact raw meta data provided when their token was minted. Simply copy & paste then substitute the values you would like to use instead and of course use your policy id and asset name as well.
Note: pool.pm tool and others sites of this kind are just “prettifying” the raw meta data of the token by looking up activity on the ledger and parsing it with some simple JavaScript for display purposes.
1 Like
I’m having a little trouble understanding what the final agreed-upon metadata entry for “artist” or “creator” is in the above conversation. With the intent to allow for an easy/standardized way of identifying a creator/artist section wherein would be a Cardano address (or list of addresses of contributing creators) for reward payments by a custom-coded application which supports rewards payments in any sales transactions.
(Cross-posted from a comment on the original PR)
This CIP does not have a Rationale section. This is important, because it needs to justify why it achieves the goals that it sets out to, and in particular why the scheme is secure. I believe it does not achieve its goals, for the reasons below.
This approach is fundamentally unsafe for the reasons discussed here: CIP-00xx | On-Chain Token Owner Key Registration by KtorZ · Pull Request #118 · cardano-foundation/CIPs · GitHub
It conflates the creator of the token with the party who performs the minting action. These are often but not always the same person, and you can’t tell without… metadata. This confusion means that if this is adopted as a a standard then anyone whose tokens don’t follow this pattern will potentially be vulnerable to metadata spoofing attacks.
The inference the CIP takes from this quote is also incorrect:
Given a token in a EUTXOma ledger, we can ask “where did this token come from?” Since tokens are always created in specific forging operations, we can always trace them back through their transaction graph to their origin.
Shortly afterwards, there is this additional sentence
In the case of fungible tokens, there may be multiple possible traces: since such tokens are
interchangeable, if two tokens of some asset are forged separately, and then later mingled in the
same output, then we cannot say which one came from which forging.
That is, there is only a unique origin for non-fungible tokens. But whether a token is fungible or not is a global property, so you can’t tell whether it is or not without… metadata.
I try to understand your issue.
If I grasp that correctly, the problem was not really relevant as long as there were only native scripts. If the policy script says that anyone can freely mint, it is a kind of strange token, but it would seem consistent that also anybody can set the metadata for that token.
Your examples become relevant, when Plutus scripts enter, because then I can allow anybody to mint provided that certain conditions are met (a fee transferred to me, a collateral bound in the contract, …).
Haven’t come to look at Plutus in detail, but can’t we forbid additional metadata in transactions with a Plutus contract? Would perhaps be a good idea, anyway.
Marking as required seems to me as incorrect behavior. At worse if an NFT has no image then a wallet / ‘user’ could fall back on the asset name (centered in a div or something), this seems to be the default behavior with most ‘wallets’. I would suggest altering CIP 25 to change image from required to suggested.
Wondering if anyone else believe this should also be the case for consistency as currently CIP 25 suggests that if you don’t include a image your NFT metadata is invalid.
I’ve raised this an issue, as I believe the required is more of a developer desires an image tag. There are currently many NFT’s in circulation without an image tag.
The context for my concern
I’m creating a NFT parsing library that conforms to CIP 25 and related. But don’t think marking a NFT as invalid due to lack of a image property is the correct behavior. More appropriate would be a warning suggesting to use the image property to make the NFT more ‘user’ (wallet) friendly.