Yes the minting transaction should contain the right metadata, but I actually have found a more flexible way now to also update the metadata (as long the minting policy allows me to). So I assume now that the latest mint transaction that contains the 721 label is the valid one. So you can still update some of the metadata in case of mistakes. What do you think of this idea?
A version could make sense actually. How about adding a “version” property under the 721 key? And assume it’s version 0 if it’s not there.
Any IPFS gateway can find the file in the network. It just takes longer for a node that has not pinned the data initially. I wouldn’t add a centralized gateway like https://ipfs.io in the metadata actually. The hash is actually just the important thing and with ipfs:// you signal that you use the ipfs protocol, which makes it very flexible to also use any other protocol to where fetch the data from. The hash size is consistent that’s why I had no problem with ipfs:// (less than 64 bytes).
Do you mean 100 indivual NFTs with the same image or one token group with supply 100?
The idea behind other properties is that people can add whatever they want to their metadata to keep it flexible. Only image and name are key properties because this is what most 3rd party tools care about. They probably don’t go to specific in your NFT use case.
Yeah the off-chain idea was really just a thought. Haven’t used it either and probably just stick with the on-chain approach.
I think the most common protocols are IFPS and HTTPS. I don’t think there is much more and even if, you can’t even get malware if you don’t understand the protocol in first place.
For the flexible idea, you’re suggesting the latest minted transaction is taken for the same policy. Yep, that works technically (I’ve used for my WILL file and photos to test update capability). However, as a general principle, I hate it The whole idea is that once it’s minted that transaction should be gospel; if a true NFT. No if’s or buts. Mistakes are mistakes and should NOT be allowed to be amended ever. Or what’s the point? So actually, the viewing tools should always take the first transaction in time in my humble opinion.
We might not ever need the Version, but it demonstrates an agreement, allowing others to then comment and chime in with their thinking. In that way, this becomes the standard with some future flexibilty.
Agreed, yes… The tree hash in IPFS is all that is required to retrieve the file. My concern/thinking felt we should be providing the how to get it, but alas, maybe it should be left to the tool provider to determine how to obtain it (some of my thinking was trying to aid Bob when he looked at the chain; but the rest of the community wont give a darn how it works), thus having the protocol IPFS:// in this case is all that is required. The length then does fit neatly.
I meant 100 individual NFT’s for the same image, say for sequences 00 to 99. This wouldn’t be one token group as each is an individual sequence of that set. In that case, we’d need to repeat the blocks with the same IPFS for no real purpose other than to fitting the standard; that seems a bit wasteful. Having some global block (in my view) that is applicable to all others would enable it to be reduced, whilst easier to navigate.
Overtime, such as CNFT, I’m certain brand details embedded into the minting transaction will be wanted as well as many other utility uses. Embedding that over and over again for each NFT of a sequence would be wasteful as per the last paragraph, thus these ‘global’ details would be better written just once.
As for the Malware, my concern is if an NFT minting transaction embeds an image with HTTPS://somewhere and that somewhere leads to a nasty place on the net. If the viewer tool simply honours it blindly then there is always a risk to the user. I think it needs to be considered, but maybe there isn’t much that can be done; other than a warning put out like Daedalus does for metadata…
Thanks for the informative and helpful discussion about NFT metadata. I’ve been struggling with and thinking about several of the issues you have all raised, so I thought I’d share my current perspective.
Regarding vocabulary for the metadata, I’m wondering if it would be feasible to leverage semantic-web technologies (the Resource Description Framework, etc.). The semantic-web folks have dealt extensively with metadata design, and the semantic web is naturally oriented towards distribution and decentralization just as Cardano and IPFS are. Dublin-Core Metadata and other standards provide for rich and unconstrained descriptions of items like tokens. The 64-byte limit might be an issue, but RDF/JSON is generally viable for on-chain metadata, and it could link to supplementary immutable metadata on IPFS.
It would be nice to have some sort of interim convention for storing NFT metadata on chain, since it might be a while before there is a standard. I’m also a bit concerned about the scalability of the pull-request process for the cardano-token-registry.
I’m not the definite expert, but I assume the royalty aspect is something that could only be implemented by a smart contract or honoured by the marketplace which performs the escrow exchange. Given how the native tokens are held and transferred in the EUTXO model, I don’t believe there is a hook for it. Would love to hear an answer to it.
Personally, I get the full declaratiive manner of the RDF’s, but feel they are a touch heavy for what we require. Which is something that enables all Cardano NFT minters to conform to, so that external party tools can all lock onto the NFT and make them visible. Happy to conform to whatever it is, but nothing there felt lightweight enough. Why lightweight, because the bigger the transaction, the more expensive it gets. OK, we’re not talking huge money here, but it will gradually build up.
I agree on the concern about the pull-request nature of the token registry. In fact, the entire registry doesn’t make sense in my head. Since Daedalus now sensibly shows the ASCII of the assetname, I don’t see a point. Instead, Daedalus should really be using the same minting transaction as everyone else. In that way there is no ‘Process’ to follow that you may or may not complete. That registry enables you to list the name, description, logo and image. Errrr, hello, isn’t that what we are agreeing here? If we all agree the minting transaction is the master here, then the registry makes no sense to me. UNLESS it is going to be used in the future to ‘Police’ the NFT’s. Again, that fly’s in the face of this being decentralised. It seems like an after thought to maintain control on tokens. I’ve completed the process in TestNet and it works; but boy is it cumbersome and at the moment, reliant on manual intervention to push it.
I like how you’ve batched onto IPFS. In fact, I like the idea (not thought of it before) of providing the policy script etc there. For all to see, instead of keeping on our own server. That’s really neat for anyone to then go look it up and confirm that the time lock has been applied. Will likely use that. As you say though, in general, maintaining that IPFS structure is a bit clunky. Overall, I personally prefer to keep everything I can on chain; where it costs to place it there, but immutable once written.
Yes you are right, the metadata should be set in stone. As I said I can only do that as long as the minting policy allows me to. Let’s say you make a mistake and burn the token and the mint it again with the correct metadata, the first minting transaction is still there. That’s why I wanna go with the latest metadata with the label 721 is the correct one.
It’s easy to handle that on a front end for example. You can simply check if this is an ipfs link and if so you just split of “ipfs://” and just take the hash and use a gateway. But it really depends on the provider, maybe some can easily understand the IPFS protocol because they run a node, that’s why I wanna keep in general.
But why would you wanna make 100 individual NFTs with the same images. I mean yeah it would be of course better to point them to one image, but this is more like a special case to me.
If you look at ERC-721 contracts I don’t really see metadata with branding and even if, it has to be embedded in all metadata of each token as well. I think having global details is hard to achieve.
Yes this could be a concernt, but this is not something the metadata proposal needs to handle.
Yep, going with the latest works technically; so that’s down to the 3rd party to implement anyway. So that works.
Agreed on IPFS protocol part.
For spacebuds, every one of your images are unique as they are generated with their combinations that make each unique. However, many NFT’s are sold as a single piece of artwork but with a number of allocation, say 100. Thus, 00, 01, 02 … 99 will all be associated to the same piece of artwork. Yes, you could emboss the number into the artwork and generate 100 of them, but that’s wasteful if the full art is what is being minted. So your need is different to a more common need that is out there, hence my thinking is trying to have that wider view of future support.
Agreed, I looked at the ERC-721 contract specification, but don’t want to be limited by its limits. We have an opportunity here, right now, to make it better. For now, I’ll stick with a v1 but think a global detail should be considered in a future version. Let’s see how it pans out without it first. It is just more data.
Yep, agreed, forget I was even concerned about the malware issue.
Given this and the excellent work from pool.pm, happy this gets me aligned to this. I have asked pool.pm to provide comment on how the spacebuds are linked back to the site. This was something I was trying to articulate before, but badly. Where I mention about the branding, what I meant was for a way to have something in the metadata that enables a 3rd party to link not only the artwork but have a link back to the publisher site; i.e. spacebuds goes back to your explorer and shows the full NFT there. This will be required by many others, including us. We can’t expect a 3rd party to keep a table of look-ups, so this needs to be included in the spec somehow, in my opinion. There is a concern over links aging, but that shouldn’t actually be a concern of this specification.
Yes it’s down to the 3rd party, but everyone should understand this as well in order to verify the metadata of their tokens.
Why don’t you just create a token with quantity 100? Is it because you want to have unique ids for each?
Yes true, we can extend it further. But I actually see no problem just appending the brand/publisher to each metadata. It really doesn’t increase size/price for the transaction.
Got it, that makes sense. Well spacebudz.io is the main page, but I defined the metadata more universal and I didn’t wanna limit it to my page. SpaceBudz should be really something that lives on its own. But I get the idea for sure and it is applicable for many things.
For the 100, yes… Each is still a unique id. Often the lowest becomes the most valuable. This isn’t a rarity thing, it’s about the number itself. There are many other ‘collectible’ formats that use this method. I.E. have 1000 copies of the card, but people buy their favourite number. They all point back to the same thing. At the end of the day, happy to leave well alone, but reserve the right to have this pushed forward if others suggest it.
We think the discussion on format here is a good start, we will probably require “tags” or “keywords” instead of traits, which is just a naming convention thing.
But on our side we will be adding two extra fields to our metadata specific to our platform requirements:
collaborators: list of addresses/usernames
copyright: string containing copyright transfer rights of a work
Is there an option to have a custom fields field in the schema? We understand that very few NFTs will require these so they are specific to our needs.
Edit: also, the royalties field is a huge must for us. All platforms should align on this field’s usage and implement the royalties in their contracts to ensure artists can get royalties if their work crosses to different platforms.
Looks like Pool.pm (Smaug) is doing a fine job pulling in the above spec already, along with the CNFT one. As things pop up, it looks incredible! Completely justifies that if we can all agree on this standard as a basis, the entire ecosystem is going to LIGHT up… Exciting times.
1. Tags
For lightweight classification and global discovery of NFTs. Would allow for a range of community driven emergent organisational trends. Tags are a convention these days (see tiktok, insta, this forum) and are a good first step between nothing and full RDF.
2. Rights
I like the idea of a “copyright” field with a tweak to “rights” since there can be all kinds of rights attached to a creative work (eg publishing rights, reproduction rights, ticketholder rights, landowner rights etc) that allow creators to go outside the established copyright legal frameworks and world of digital art (that may be jurisdiction dependent too). Having this be an immutable ipfs based file seems right.
Discussion
What do folks think? Does including rights in the NFT make it hard to apply future amendments to the rights of the NFT? (And is that a usecases or an edge case? Should the creator/origin be the only one who should be able to change this? If so, inclusion feels right)
I left “collaborators” as something for “<other properties>” since identity is very challenging, solved by the blockchain to a degree (or will be in the future), and feels like it will be implementation specific
ASCII names are misused. These are NOT supposed to be used as “the name” of the token. The real name is a part of the token’s metadata which the creator of the token needs to register.
I wasn’t aware of the Token Registry and I agree that requiring “Name, Description” metadata on native tokens already presumes a standard.
There will be use-cases where only unique identifiers will be required as an audit trail and any additional semantic data is superfluous or undesirable (e.g. where users who want to offload/secure their metadata off-chain, require confidentiality etc.).
From the January presentation I got the impression that a minimal approach was being taken where there is provision for more extensive metadata (at a cost). But certainly not prescriptive metadata standards in a CIP.
This approach made sense to me because there will always be many metadata standards for NFTs from museum artefacts (Dublin Core, RDF etc) to encrypted legal documents (that only require a key pair). And these varied use cases may decide to either plug into the minimum (via unique references) or burn some of their key fields onchain.
On pool.pm/tokens, SpaceBudz NFTs are actually links to their official website page, which is an interesting feature I think (the other NFTs just open the image link in a new tab for now).
@CrazyCareer started discussing if this could be part of the standard. Feature wise I think it would be nice, but I’m afraid long term of abandoned domains hijacks for scam once there is no incentive to pay for them anymore (even without scams, websites will be abandoned too leading to 404 or like).
So I’m not sure what to think about that. Could there be a way to provide some additional information that would allow to check that the link is legit?
Hi there, what do you think about putting all this things together… So we can have a extensible properties section, a convention about the “tags” naming, and a way to identify the type and where the file is stored. Please feel free to iterate this schema!
The whole idea is that once it’s minted that transaction should be gospel; if a true NFT. No if’s or buts. Mistakes are mistakes and should NOT be allowed to be amended ever. Or what’s the point? 
So actually, the viewing tools should always take the first transaction in time in my humble opinion.