NFT metadata extension tag

[Jack-0]

Related to discussion generated by CIP48

A standard proposing to add the ext tag under the 721 metadatum tag.

As Cardano NFT's grow so do the optional metadata tags included inside the metadata under the 721 metadatum. Here I propose a way to standardize optional metadata.

This is required as the NFT space on Cardano (CNFT) grows so do our optional NFT parameters. This standard will make NFT parsing simple, modular and easier to maintain. Thus making the CNFT space more accessible to developers.

I was motivated to create this CIP after attempting to parse CNFT's myself and noticing the amount of optional parameters inside the metadata that are not clearly defined. This could lead to some developer using an optional tag that unknowingly and then seeing there NFT represented incorrectly on a third party site.

In parallel to this CIP I have opensourced an NFT parsing library (still in early beta). I wish to create a library that supports all NFT standards on Cardano so developers can generate, verify and parse metadata with confidence.

---

new proposal draft
updated draft of CIP-0025

[rphair]

thanks for splitting this from #249 @Jack-0 ... can you leave this document in the CIP-0048 subdirectory but rename the file itself to README.md?

[rphair]

This method has been considered a Candidate CIP based on #249 discussion & also applying the Process tag as such.

[rphair]

@Jack-0 there's still a typo in the name of your document file (a repeated dot): CIP-0049/README..md

[rphair]

@Jack-0 can you put your proposal in an unnumbered but descriptive subdirectory (renamed from CIP-0049) and remove the CIP number from the document header? There's currently a collision with a prior dated candidate CIP-0049: #250

[KtorZ]

I did rename the title already.

As discussed during the meeting today, this CIP is not receivable as it stands. There's very little information as for what the specification actually is. I encourage you to maybe bring the problem you're trying to solve forth in discussion with other builders of the ecosystem and come back with a solid proposal. Please take the time to write your idea down properly and to organize your thoughts.

[Jack-0]

The idea is very simple.

Add an ext property to the metadata and reference the used CIP's in an array. Then when parsing the metadata we will know that it contains key reserved properties that related to a existing CIP.

For example take smart NFTs https://github.com/cardano-foundation/CIPs/pull/263/files
In which the uses property is defined. Without the ext extension tag I don't explicitly know that uses is reserved for some functionality. If instead the nft has declared ext:['cip0058'] a "user"/"front-end" knows they need to apply some function or look to cip58 to understand the properties in the metadata.

At this current point in time we keep adding more optional functionality to metadata. We should announce these extensions to the metadata with an extension tag.

Sorry if this looks to be poorly written, I will try to improve my communication, I would love to attend the meeting but I work full time and work on Cardano related stuff in my available free hours.

[Jack-0]

• The goal here, is to bring clarity to the metadata. To ensure that optional JSON properties that keep getting added with new NFT related CIPs are defined explicitly.

[KtorZ]

This proposal on its own isn't probably a good idea; Rather, making it part of CIP-0025 could make sense and be discussed further. In particular, assume this proposal is merged, what would prevent a competing extension mechanism for CIP-00025 to also be proposed; which one would one have to support? In this case, I think it is better to update CIP-0025 directly to include an optional extension mechanism.

The motivation I think, is relatively clear (i.e provide an extensibility mechanism to CIP-0025) but isn't actually stated as motivation in the document, which focuses instead on the difficulty to parse metadata (and arguably propose a change to make it slightly harder to parse :s).

Keep in mind also that the chain does not understand JSON and CIP-0025 is not specified in JSON either. The extension should be described as CBOR.

[SebastienGllmt]

Keep in mind also that the chain does not understand JSON and CIP-0025 is not specified in JSON either. The extension should be described as CBOR.

Agreed. I think a proper solution would describe how extensions can define a CDDL specification and then some description on how merging specifications with overlapping keys should be handled.

I think the main rationale for this CIP is actually trying to have a way to know which type a specific key is which JSON definitions don't give you

[rphair]

@Jack-0 the idea to rephrase this as an update to CIP-0025 was favourably received at today's CIP meeting. We could see that your draft at this time is already modifying CIP-0025 a bit: therefore I suggested you could continue on with this PR rather than closing this & creating a new one.

[rphair]

@alessandrokonrad I should have included you in the above comment to keep the discussion more concise. What do you think about an extension mechanism to CIP-0025 (documented in the CIP itself) and how this tag syntax might fit into it?

[Jack-0]

Yeah I was planning for this to be a extension of cip25 I did not make that clear. Thanks for taking the time to review!

Actions:

• Alter CIP-25 definition in this PR with updated CDDL
• Look at CIP-68 and consider if that also is impacted by these changes.

[rphair]

@Jack-0 (cc @KtorZ) I think we are "Waiting for Author" again because of the pending issues: a clear specification along with the problem this is trying to solve (comment, comment) and integrating it properly with CIP-0025 and hopefully its authors to agree on how to extend it in general (comment).

If we decide at today's CIP Editors' Meeting to close this, please include progressing these issues as part of any plan to re-open it. 🙏

[rphair]

@Jack-0 if you still want to bring this forward it might still exist as a parallel standard, but FYI another CIP has become a candidate which handles the data reference problem in a way that also provides a public-key system to authenticate those references:

https://github.com/Crypto2099/CIPs/blob/token-registration/CIP-XXXX/README.md#example-3-de-duplication-of-data

Therefore, is it OK that we close this as superseded by the pending CIP-0088? I'm also inviting the author of that CIP to comment here in case there are any reasons to keep this one going in parallel. Otherwise with no other supportive action taken we will probably close this soon.

[Jack-0]

If there is active work on cip 88? and this provides a mechanism to allow the user / developer to make sense of cip25 metadata then this CIP maybe deprecated by that work.

[Jack-0]

I've made some notes on CIP88? there seems to be overlap between these two CIPS I'm happy to adopt either one as both solve the same issue with different approaches.

#467 (comment)

[rphair]

As per #249 (comment) we are closing this associated PR for the same reason, after review in CIP meeting today to see if there were any last calls before deprecation.