CIP - NFT Metadata Standard

There is no noise, if you look for the forging transaction.

that’s true. the standard won’t restrict anyone, but usually an NFT contains an image and a name. so this is what a wallet for example will display. any other properties can be defined how they want and be displayed on the specific NFT platform.

I meant noise which is in the whole chain and not in your already filtered db.
For example a third party wallet just import the publisher key it is much quicker for its metadata server (why would he trust you? And querying its metadata servers just for those metadata based on the keys. As he would not like query you cos you can cheat.

And there can be thousand of token controllers etc.

But, yeah if every metadata server would use the same db as you then your solution would be good too.

no this is not my db, this is from db-sync. so as wallet you just run cardano-node and db-sync and filter out the metadata on your own. no one to trust here.

Uuugh, sorry I thought it is customised as I have not played with db sync

hahaha no :slight_smile:
I keep everything as decentralized as possible.

1 Like

Also, keep in mind that you cannot do pure NFT with UTXOma (native/multisig script) as you can mint an other token whenever you want, even if it has initially just one token, as the forging right is in the token controller’s (and not in the monetary policy’s) hand, and you know…

Also, the second issue I can see, that when the metadata is added only in to the forging tx, then that probably mean that the metadata is immutable for that pseudo-nft, though you can hack it when you mint an other nft later with the same policy id (i.e. you can add an updated metadata for the prev nft), but imo it’s not practical.

Anyway, I think that:

  • Plutus core should be used with proper monetary policy (enforce real non-fungibility along with other features)
  • Metadata, should be used for non-static human readable properties (though it can be used for static ones e.g. symbol if the smart contracts does not offer that feature), such as description, image, avatar etc.

But the rotation of the nft’s metadata is problematic (though the key based authenticity could solve this issue).

1 Like

With a state machine you can restrict someone from minting the same token twice.

1 Like

Yeah, and the Plutus core is a pure state machine, while the (current) native script is not.

Sure I don’t say the policy shouldn’t be done in Plutus. If we use Plutus for it, I don’t see any problem with my metadata proposal.

1 Like

Yes, sorry. Initially, I was in the impression: trying to implement the NFT standard in metadata when I was scanning through the posts, which does not make any sense to me. But, I could, as I was several times in my life, be wrong.

And ofc, using metadata for nft or even ft makes sense. But, I do not think that a standard would help, as the fields who will implement end use these features are very broad, and probably almost every participants probably would need different key value pairs in the metadata. As I imagine it as a NoSQL (key value store like) Firebase, Mongodb or similar in which every app developer use their own structure that is based on their requirement, even then when for example user personas could be standardised.

So, that is why I see some caveats for these kind of proposals, but as I told I could be wrong and thes kind of efforts could evolve to some standard.

Even not every metadata server would index/filter the same metadata, and it will be very target specific based on the dapp developers. For example the NB (New Balance as the reference to a past deal) would filter/index only their metadata for several reasons (GDPR, illegal contents etc)

As I said the metadata are on-chain and not on an extra metadata server. You just need db-sync and can get all information in a trustless/decentralized way.
I had been developing smart contracts for quite a while on ethereum especially in the area of NFTs with the ERC721 token. I can say of my experience a metadata standard is crucial.

I would not reply, and this will be my last, but unfortunately there is some misleading information to the community in these sentences, what I need to clarify. And the second part of your post, seems to me law of authority or simply an appeal to authority, and I won’t consider it seriously.

Yes, the metadata is on the chain (no one said the opposite), what the consensus rules do not consider seriously in their validation (not really true but for the sake of simplicity it is enough). Even they are not int the ledger state at all, so a Daedalus (the only real trustless and decentralised wallet in Cardano) cannot get any info and state of them.

The trustless information only resides in the full nodes (that is the on chain) and not on db-sync (off chain), metadata server (off chain) etc.

Therefore your db-sync statement is invalid as anybody can spin up a db-sync and sync it wiht a full node and alter its data later whatever they want and provide and API for the public, it is not trustless nor decentralised.

Only, trustless information what a wallet can get (related to its coin) is the UTXOs where the coin and its tokens (and only the policyid assetname pairs) are available trustless to the wallet.

That’s why there are efforts like metadata proxies for pools for example to overcome of these issues, but it’s a bit early to discuss about them.

If you argument like that, you can’t trust Adapools, Pooltool, Yoroi and any other explorer or light wallet.
It’s simply not possible to use only the cardano-node for all cases. But well cardano-node is also just a repository, how can you know that this one is legit? Well you obviously trust IOG.

In the worst case scenario, when your provider is cheating on you, you can always verify on your own what the real metadata are. This is what it’s all about.

3 Likes

Adding strong support for a metadata standard. Without such a thing building discovery and marketplaces for NFTs becomes extremely challenging.

1 Like

Hi Alessandro,

I’d not got round to responding to this. I concur with the findings here, that the DB Sync table gives us tracability from Policy → Minting Transaction Id → Metadata, thus for 3rd party providers, this is definitely the answer to the homework.

For the standard above, I like it, but questions/thoughts?

  • Do you think there should be a version in there? So that if we have a common agreement now but in the future want to deviate, the version enables the third parties to work from it to determine expected format?

  • With the image tag, have you not run into the 64byte limit when tagging in the TREE HASH of IPFS? I certainly have. So I can’t shorten it to ipfs/<IPFS_HASH> because who ever picks it up needs to know what third part service is going to provide the file. That really concerns me, and wondered whether there should be two parts to the image url. The first is the url (or uri if you like) and the second the path to the image. This then ensures the third party goes to the right provider AND the content. Unfortunately, this is a restriction based on the 64bytes. It will be worse when OTHER types of content is thrown up too.

  • Given the issue of size of metadata. If I decide to generate 100 tokens for the one image, the initial idea requires 100 repetitive blocks, eating a lot more space. Would it not be sensible to have the image or more importantly “asset” be in a block of it’s own. Thus, you can then simply have a list of the token numbers? That both reduces the size of the payload but also makes it far easier for the third party to process? i.e. they only have to pull out the one image rather than having to loop through 100 blocks and check every image is the same?

  • I appreciate the ‘other properties’, but don’t we want to consider other standards, such as Ticker (if there is associations) or links back to authoring sites? Clearly this may be less important, but again, for a third party tool provider, this might be better specified so they can easily lock on to it.

I personally dislike the offchain idea, but completely get why that is proposed. It does save on cost, but if IPFS disappeared forever (no matter how unlikely), that means it’s gone. Storing it on chain is the only option for me.

Thanks for the write up of this! This is something we desperately need agreed sooner rather than later.

1 Like

In fact, the more I think about my second point, we also need to think about HOW it can be used by a bad actor. Can they supply a URL that potentially has malware on the end of it or a tracker? So actually, in my opinion, maybe we have the ‘path’ part as discussed, but we have a LIST of agreed protocols, i.e. IPFS that maps to https://ipfs.io/ so that more can be introduced. In this way, the third party can implement that, safely knowing what the agree list; this maps to good OWASP practice where you have to use tokens to represent redirections without giving an injection possibility… Again, just a thought to stimulate discussion.