Skip to content
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

CIP-0086 | NFT Metadata Update Oracles #430

Merged
merged 26 commits into from
May 2, 2023

Conversation

nicolasayotte
Copy link
Contributor

@nicolasayotte nicolasayotte commented Jan 16, 2023

@mathieu2em
Copy link

Definitely a useful feature that would come handy for a lot of Cardano NFT projects. As someone working with a lot of them I can already view many different places where this would be useful. Thank you so much for the work done here ! +1 love to the regex integration.

@MicroProofs
Copy link
Contributor

I think you should incorporate CIP-67 (the label standard). This would help with offchain being able to easily identify tokens following this standard. CIP-67 can be updated to include a label to reflect the usage of this standard.

@GeorgeFlerovsky
Copy link
Contributor

I think you should incorporate CIP-67 (the label standard). This would help with offchain being able to easily identify tokens following this standard. CIP-67 can be updated to include a label to reflect the usage of this standard.

Thanks for your suggestion. We'll check it out!

@nicolasayotte
Copy link
Contributor Author

I think you should incorporate CIP-67 (the label standard). This would help with offchain being able to easily identify tokens following this standard. CIP-67 can be updated to include a label to reflect the usage of this standard.

As such, our standard is agnostic to the exact asset names representation and, from what I can surmise, our CIP technically supports CIP-67 as-is.

CIP-67 is an interesting concept: maybe its registry should include a label for CIP-25 standard NFTs?

@the-Minister-0001
Copy link

Hey Nicolas, thanks for sharing this!
I think the functionality you described would enrich a lot of projects, let alone the one you're working on.

Nice to see you formulating out what you're doing for your fairly large scale application! Hopefully it'll benefit other projects, too!

@huths0lo
Copy link
Contributor

This is a rather novel approach to what will become a significant problem in the future. I've personally had to overcome the challenge of updating metadata on the Cardano Budz GYOA platform. Since no other option exists, I went the route of reminting the assets every time an update is needed. But I did this knowing that there was major downsides, with no alternative solution:

  1. Cost for reminting (Shouldered by the project owner, or asset owner)
  2. Blockchain bloat
  3. Additional complexity for maintaining NFT status by ensuring the extra token created is burned
  4. Not being able to use a locking policy on the assets

I think this is a very novel approach to solving these inherent problems of reminting tokens. There is no overly complex approach to proving you are the original owner, as you are repurposing the policy skey as a Cardano Wallet. It addresses that some NFT projects may want to prove they will never remint their assets by providing an on chain mechanism. It addresses the burden of having to index these updates for general use. It addresses using regex to allow for mass updates. And it simplifies the updating of many issues in a singular transaction, instead of many. Although you could update many tokens already, this makes it much simpler since the updates wouldnt require additional asset management.

@SmaugPool
Copy link
Contributor

SmaugPool commented Jan 16, 2023

Hi,

What about CIP25 version 2 where the policy ID and asset name are encoded as byte strings?

The asset name may not be decodable as UTF-8 so how would the asset name in updates be specified and how would regex & tabular updates work?

@GeorgeFlerovsky
Copy link
Contributor

Hi,

What about CIP25 version 2 where the policy ID and asset name are encoded as byte strings?

The asset name may not be decodable as UTF-8 so how would the asset name in updates be specified and how would regex & tabular updates work?

Good point about non UTF-8 token names. I guess the easy answer to that would be to disqualify such tokens (with non-text token names) from being updatable by our CIP's regex and tabular mechanisms.

They might still be eligible for our simple update mechanism, so they would still benefit from our CIP because they wouldn't need to remint to update token metadata.

Do you have an alternative suggestion to handle this?

@rphair rphair changed the title Proposing NFT Metadata Update Oracles CIP-???? | NFT Metadata Update Oracles Jan 17, 2023
@SmaugPool
Copy link
Contributor

They might still be eligible for our simple update mechanism

How? It seems that the asset name is also a string in the simple update mechanism.

As an aside one benefit of CIP25v2 beyond allowing non-text asset names is that byte strings are half as long as hex strings so this saves some space in the blockchain for the policy ID at least. Maybe this could have been considered for this CIP too.


```json
{
"????": {
Copy link
Contributor

@SebastienGllmt SebastienGllmt Jan 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add cddl definitions for all of these? Since those are what are actually stored on the ledger

You can look at the CIP25 cddl spec for reference

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea! Thanks

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, certainly. We'll add the CDDL definitions for everything, this week.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GeorgeFlerovsky I am working on it, btw. :D

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SebastienGllmt @SmaugPool
We've added CDDL files to our proposal.

Similar to CIP-25, we have:

  • cddl/version_1.cddl for text-based policy IDs and asset names.
  • cddl/version_2.cddl for bytes-based policy IDs and asset names.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SebastienGllmt we had added the definition files

@GeorgeFlerovsky
Copy link
Contributor

They might still be eligible for our simple update mechanism

How? It seems that the asset name is also a string in the simple update mechanism.

As an aside one benefit of CIP25v2 beyond allowing non-text asset names is that byte strings are half as long as hex strings so this saves some space in the blockchain for the policy ID at least. Maybe this could have been considered for this CIP too.

Ah, right. We would indeed have to use an alternative to text-based JSON field names if we want to support non-text asset names. I'll check out CIP-25-v2 to see if we can adapt their approach to our CIP.

@nicolasayotte
Copy link
Contributor Author

They might still be eligible for our simple update mechanism

How? It seems that the asset name is also a string in the simple update mechanism.

As an aside one benefit of CIP25v2 beyond allowing non-text asset names is that byte strings are half as long as hex strings so this saves some space in the blockchain for the policy ID at least. Maybe this could have been considered for this CIP too.

I am sure we can have the policy id and asset name level tag support CIP-25-v2 with a version tag at least for simple updates. For the bulk updates, I will have to think about how / if those can be implemented.

@rphair
Copy link
Collaborator

rphair commented Jan 18, 2023

thanks @GeorgeFlerovsky for #439 (comment) and you are welcome to add the H1 and make the other sections H2. 🤓 The exact (longer) titles for the Motivation and Rationale sections are listed in https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001#structure (see also background at #439 (comment))

CIP-????/README.md Outdated Show resolved Hide resolved
Copy link
Collaborator

@rphair rphair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GeorgeFlerovsky in your next revision, including

can you also...

CIP-????/README.md Outdated Show resolved Hide resolved
CIP-????/README.md Outdated Show resolved Hide resolved
@rphair
Copy link
Collaborator

rphair commented Feb 14, 2023

@alessandrokonrad we were just saying in the CIP meeting now that maybe you could also give a review of this?

Co-authored-by: Matthias Benkort <[email protected]>
@nicolasayotte
Copy link
Contributor Author

Does it need to be fully backwards compatible to CIP-0025? As it was pointed out in several other CIP discussions CIP-0025 is flawed and allows for spoofing attacks. Forcing asset names to have a label (CIP-0067) reduce that attack vector significantly. And I think this CIP should consider this and only recognize CIP-0025 assets that follow a specific label.

Well, it doesn't need to be fully backwards compatible, but it would more enabling for all the early projects that promised gamification (especially those that are now policy locked and cannot adapt their NFTs) if we are. As you are well aware, innovative NFT standards exist that provide higher functionality for the future of Cardano (like CIP-68). CIP-86 is tailored for projects that either already launched their collection, or do not want (or are unable) to switch to Smart Contracts development to manage all the possible states of their NFTs.

Copy link
Collaborator

@rphair rphair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nicolasayotte @GeorgeFlerovsky looks ready to go after last round of edits, with almost all feedback incorporated... it sounds to me like #430 (comment) has an indirect answer in the Token metadata indexer section (?).

Just please first rename folder CIP-???? to CIP-0086 and then I'm happy to approve this 🤓

@nicolasayotte
Copy link
Contributor Author

nicolasayotte commented Mar 2, 2023

@nicolasayotte @GeorgeFlerovsky looks ready to go after last round of edits, with almost all feedback incorporated... it sounds to me like #430 (comment) has an indirect answer in the Token metadata indexer section (?).

Just please first rename folder CIP-???? to CIP-0086 and then I'm happy to approve this 🤓

I renamed the folder! 🎉

Copy link
Collaborator

@rphair rphair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes @nicolasayotte it's been renamed... but with some files (README.md, *.cddl) now duplicated into a CIP-???? directory 😖 ... after this is fixed we should also check the links to subordinate files from README.md because of the duplication.

@nicolasayotte
Copy link
Contributor Author

nicolasayotte commented Mar 3, 2023

yes @nicolasayotte it's been renamed... but with some files (README.md, *.cddl) now duplicated into a CIP-???? directory 😖 ... after this is fixed we should also check the links to subordinate files from README.md because of the duplication.

I will try again: "?" in a path on Windows simply doesn't work at all, so I am going through WSL to do this and apparently messed it up. 😝

@nicolasayotte
Copy link
Contributor Author

@rphair fixed correctly this time. 👍

@rphair rphair requested a review from KtorZ March 3, 2023 16:39
@nftguild
Copy link

@nicolasayotte , the main contributor to CIP 86, gives an overview of what the CIP is all about and what it’s trying to accomplish, in this short video:

Intro to CIP 86 - NFT Metadata Update Oracles
https://youtu.be/HN40XybkAKs

You can also watch the entire NFT Guild roundtable discussion:
https://youtu.be/Du3Csxwt7cU

Transcript: https://drive.google.com/file/d/1L6cz1PlBWK5bKCLCr2YytDIJypynIiC7/view?usp=share_link

@KtorZ KtorZ added the Category: Metadata Proposals belonging to the 'Metadata' category. label Mar 18, 2023
@rphair rphair requested review from SebastienGllmt and Ryun1 April 27, 2023 11:53
@rphair
Copy link
Collaborator

rphair commented Apr 27, 2023

@KtorZ I think this will be a good inclusion for Review at our next CIP meeting (currently scheduled for 02 May) since I believe the author has addressed all feedback adequately and there is good community support for this. 🤩

@rphair
Copy link
Collaborator

rphair commented May 2, 2023

resounding approval at CIP meeting just ended now... @KtorZ it sounded like you were happy with it; would you like to do 1 more green-check review & merge? 🤠

Copy link
Collaborator

@Ryun1 Ryun1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following todays meeting, it appears all community concerns have been addressed by the authors and there is no significant disagreement stopping this from moving to be merged as proposed.

@rphair rphair merged commit b4e27dd into cardano-foundation:master May 2, 2023
@rphair rphair changed the title CIP-0086? | NFT Metadata Update Oracles CIP-0086 | NFT Metadata Update Oracles May 24, 2023
Ryun1 pushed a commit to Ryun1/CIPs that referenced this pull request Jul 28, 2023
* Proposing NFT Metadata Update Oracles

* (administrative) filled in CIP GH PR link

* Demote top level headers to H2 + add H1 title

cardano-foundation#430 (comment)

* Fix internal section links

cardano-foundation#430 (comment)

* Fix link/code typos

* Add CDDL draft file

* Isolate CDDL for text-based (policy_id,asset_name)

This corresponds to the CIP-25's version_1.cddl.

* Add support for bytestring (policy_id, asset_name)

This corresponds to CIP-25's version_2.cddl.
Note that regex and tabular updates are not supported under this
version 2 mode.

* Update version_1.cddl

typo in text_32 definition

* Update version_2.cddl

typo in text_32 definition

* Update CIP-????/README.md

Co-authored-by: Matthias Benkort <[email protected]>

* Update CIP-????/README.md

Co-authored-by: Matthias Benkort <[email protected]>

* Update CIP-????/README.md

Co-authored-by: Matthias Benkort <[email protected]>

* Update CIP-????/README.md

Co-authored-by: Matthias Benkort <[email protected]>

* Apply semantic line breaks to README

See [Semantic Line Breaks](https://sembr.org/)

* Apply CIP-86 number to all its documents

Replacing all instances of "????" with "86".

* Replace CSV with JSON in tabular updates

* Add tabular updates to version_2

* Add "Versions 1 and 2" section to README

* Fix indent consistency

* chore(CIP-0086) rename the folder

* fix: duplicated files

---------

Co-authored-by: Robert Phair <[email protected]>
Co-authored-by: George Flerovsky <[email protected]>
Co-authored-by: Matthias Benkort <[email protected]>
Ryun1 pushed a commit to Ryun1/CIPs that referenced this pull request Nov 17, 2023
* Proposing NFT Metadata Update Oracles

* (administrative) filled in CIP GH PR link

* Demote top level headers to H2 + add H1 title

cardano-foundation#430 (comment)

* Fix internal section links

cardano-foundation#430 (comment)

* Fix link/code typos

* Add CDDL draft file

* Isolate CDDL for text-based (policy_id,asset_name)

This corresponds to the CIP-25's version_1.cddl.

* Add support for bytestring (policy_id, asset_name)

This corresponds to CIP-25's version_2.cddl.
Note that regex and tabular updates are not supported under this
version 2 mode.

* Update version_1.cddl

typo in text_32 definition

* Update version_2.cddl

typo in text_32 definition

* Update CIP-????/README.md

Co-authored-by: Matthias Benkort <[email protected]>

* Update CIP-????/README.md

Co-authored-by: Matthias Benkort <[email protected]>

* Update CIP-????/README.md

Co-authored-by: Matthias Benkort <[email protected]>

* Update CIP-????/README.md

Co-authored-by: Matthias Benkort <[email protected]>

* Apply semantic line breaks to README

See [Semantic Line Breaks](https://sembr.org/)

* Apply CIP-86 number to all its documents

Replacing all instances of "????" with "86".

* Replace CSV with JSON in tabular updates

* Add tabular updates to version_2

* Add "Versions 1 and 2" section to README

* Fix indent consistency

* chore(CIP-0086) rename the folder

* fix: duplicated files

---------

Co-authored-by: Robert Phair <[email protected]>
Co-authored-by: George Flerovsky <[email protected]>
Co-authored-by: Matthias Benkort <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Metadata Proposals belonging to the 'Metadata' category.
Projects
None yet
Development

Successfully merging this pull request may close these issues.