Skip to content

Conversation

@Kammerlo
Copy link
Member

@Kammerlo Kammerlo commented Jul 8, 2025

We are launching Reeve today and we decided to move the label to 1447.
Our transactions are published under this label already.

The documentation of the onChain format is here: Link

@Ryun1
Copy link
Collaborator

Ryun1 commented Jul 8, 2025

Hey @Kammerlo

just to be safe -- is there any danger in changing this? could it break any implementations?

and the supplied documentation seems to have moved from the link

@matiwinnetou
Copy link
Contributor

matiwinnetou commented Jul 8, 2025

It would make 2023 CF data (soft Reeve launch) maybe not invalid but it was using different label, the one that is being removed.

@rphair
Copy link
Collaborator

rphair commented Jul 9, 2025

@matiwinnetou (cc @Kammerlo) what about keeping the old tag number in there as a "legacy" metadata tag... titled something clearly not current like Reeve - legacy (pre-launch) metadata (obsolete)?

@rphair rphair changed the title docs: Changing Reeve metadata label after the official launch CIP-0010: Change Reeve metadata label after the official launch Jul 9, 2025
@rphair rphair added the CIP-0010: new registry entry Adding a new entry to the metadata label registry label Jul 9, 2025
@Kammerlo
Copy link
Member Author

Kammerlo commented Jul 9, 2025

Yes as Mati said, the softlaunch data is published under the "old" label. But with the launch the new label is what matters. And the old one is obsolete. I will add it for documentar purposes, but will add that it's obsolete.
@Ryun1 @rphair

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.

thanks, that seems more robust for posterity's sake.

@Kammerlo @matiwinnetou while we have you here, representing a typical & fairly demanding application: what do think of this tentative proposal to allow a "schema" as an optional field of CIP-0010, allowing metadata to be intelligently displayed (and maybe interpreted) by third parties?

@rphair rphair added the State: Triage Applied to new PR afer editor cleanup on GitHub, pending CIP meeting introduction. label Jul 9, 2025
@rphair rphair requested review from Crypto2099, Ryun1 and perturbing July 9, 2025 17:44
@rphair rphair added State: Last Check Review favourable with disputes resolved; staged for merging. and removed State: Triage Applied to new PR afer editor cleanup on GitHub, pending CIP meeting introduction. labels Jul 9, 2025
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.

great!

thanks @Kammerlo @matiwinnetou 💪

@rphair rphair merged commit f47ac4b into cardano-foundation:master Jul 10, 2025
2 checks passed
@rphair rphair removed the State: Last Check Review favourable with disputes resolved; staged for merging. label Jul 10, 2025
@Kammerlo
Copy link
Member Author

@rphair Yes I think it's a good point from @Godspeed-exe
When I submitted my first CIP-10 metadata label: I checked how others linked the metadata description and thought that having it in the PR note (as far I did it this way, since others did the same) is a little bit unhandy. So harder to find for users, if they want to understand it.

I like the approach, that it's optional. There might be usecases which want to just "block" the label, but if there is a usecase which wants others to really understand it this registry is the first place a user will check. Perhaps another field like an url to the project makes sense as well, but this would be more for human-readability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CIP-0010: new registry entry Adding a new entry to the metadata label registry

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants