CIP-0100? | Governance Metadata

[Quantumplation]

This CIP is the second draft for a standard surrounding any "metadata" attached to the activities that users engage in during governance.

The first draft, along with comments left by some members of the Cardano community, can be found here:
https://gist.github.com/Quantumplation/56ef2ffccb05f5d2974fd17240dc406c

A recording of the workshop held to solicit feedback that went into this second draft can be found here:
https://www.youtube.com/watch?v=TnPJ11Po04s

There are some <!-- inline comments --> with notes from various workshops, if you're curious, but that aren't relevant to the main CIP.

There are some open questions in the form of task lists that I could use some help answering.

Rendered

[Ryun1]

Hello @Quantumplation!

Thank you for kicking this off, looking forward to seeing this proposal develop 😎.

[rphair]

@Quantumplation I've read through the proposal and think the formalisation of terms, both human- and machine-readable, could only be an improvement. I'm still trying to catch up with the recent discussion of CIP-1694 so I'm not qualified to dispute any of the details: but I support this CIP in general assuming other reviewers can sign off on the specifics.

There are some with open questions or places where I could use some additional assistance ... (note: several inline comments won't be visible in the rendered version)

I read those comments in source from a clone of this branch, and I think your (and our, as reviewers) purpose would best be served by immediately making these comments visible in a way that encourages review. Some comment sections look like working notes, but the others are open questions that need to be highlighted rather than suppressed...

Using a task item / list for these would be consistent with items for continued attention & resolution in our CIP format already, as well as a standard for GitHub issues, and:

• The attention to this draft from @thenic95 on the Forum means we may get a lot of readers who won't necessarily view the GitHub document source but still should be included in your feedback (e.g. in workshops).
• The tasks list will make it very clear these items are inviting discussion.
• These items would be deleted and/or turned into normal prose in the editing & review process and will not be in the finally approved & merged CIP... and if not resolved in review, they might be moved into the Path to Active where they could remain formatted as task items. 😎

[rphair]

@Quantumplation this is up for introduction at today's CIP Editors' Meeting at 4PM UTC; it would be nice if you could be there, though not planning on a detailed review at the meeting (https://hackmd.io/@cip-editors/70).

I was expecting more community feedback about this, especially with the Forum introduction, but without any dispute I'm going to recommend this be given a CIP number so hopefully it can march forward into wider review.

[Quantumplation]

@rphair I won't be able to make it exactly at 4pm UTC, as that's when we have standup, but I can join 10-15 minutes later!

[rphair]

@Quantumplation thanks for a great introduction at the CIP editors' meeting today where we were all happy to confirm candidacy for this proposal. Whatever you can recall of the Q&A that followed, please make an effort to record it here. 🙏

One highlight that I will recall from that discussion is this proposal's suitability to define a vocabulary for on-chain governance matters even if the rules & Ledger implementation end up being different than what is currently under consideration.

[Quantumplation]

The bulk of the discussion in the CIP editors meeting was focused around the motivations for this proposal, how to handle versioning, and how much to specify here vs other proposals.

The main takeaway was that this defines a very basic MVG of properties, which are shared by all types of governance actions; and how a subsequent draft of this will probably limit it to just those properties, and leave extensions up to other CIPs.

[l-br1]

Below is a list of fields I think we should include in Governance Action metadata (assuming they come from discussions happening off-chain).

[GA = Governance Action]

These can be included and expand the already proposed 'Justification' field:

• Title > this provides initial context about the GA and it should make it easier (both off-chain and on-chain) to differentiate and identify GAs
• Summary / abstract > this provides the initial overview of the problem/reason related to the submission of the GA allowing anyone (especially voters) to understand the context behind the GA
• Motivation / Problem > this should detail the problem / motivation that is driving the GA
• Rational > this reinforce the Motivation / Problem and should expand on the proposed solution (AKA provide context on the actual GA. Ex. 'So I propose to change parameter X to Y)
• Supporting Links > This allows the proposer to add extra relevant information about themselves as proposers, or about the proposal itself (for example to add links to other discussions or evaluations or audits ...)

[gitmachtl]

Is there a fields-list yet for dRep registration?

[Ryun1]

@gitmachtl

Is there a fields-list yet for dRep registration?

Not yet -- any ideas? 🤓

[gitmachtl]

@gitmachtl

Is there a fields-list yet for dRep registration?

Not yet -- any ideas? 🤓

hmm... maybe something general like:

{
  "id": "drepid again",
  "about": {
    "name": "full name",
    "image": "url to an image, http(s)/ipfs",
    "desc": "a short description about the drep",
    "link": "url to a website, etc",
    "tags": "separated tags to describe the purpose of the drep",
    "location": "country/town where the drep is located"
  },
  "contact": {
    "email": "example@dot.com",
    "twitter": "mytwitterhandle",
    "x": "mytwitterhandle",
    "telegram": "mytelegramhandle",
    "facebook": "",
    "youtube": "",
    "twitch": "",
    "discord": "",
    "github": "",
    "patreon": "",
    "linkedin": "",
    "adahandle": "$myadahandle"
  }
}

not sure what was discussed in the workshops about being a drep and what infos to share in the registration.

[rphair]

@Quantumplation recording from CIP meeting today that we're looking forward to documentation of your workshop feedback and waiting for your planned changes in response. Personally I'm looking forward to the details of URL interaction as per CIP-0013. 👍 cc @scarmuega

[Ryun1]

Suggested change

This Cardano Improvement Proposal (CIP) introduces a standardized and flexible metadata format for governance actions in the Cardano ecosystem. While the ledger does not enforce the structure of metadata, providing a standard for metadata will enable better tooling, improved interoperability, and more consistent display across wallets, blockchain explorers, and other tools. This CIP aims to strike a balance between flexibility and structure to facilitate high-quality tooling, without limiting expressivity with regards to user expression.

This Cardano Improvement Proposal (CIP) introduces a standardized and flexible metadata format for governance events in the Cardano ecosystem. While the ledger does not enforce the structure of metadata, providing a standard for metadata will enable better tooling, improved interoperability, and more consistent display across wallets, blockchain explorers, and other tools. This CIP aims to strike a balance between flexibility and structure to facilitate high-quality tooling, without limiting expressivity with regards to user expression.

Since CIP-1694 defines the term "governance action" I think the term's use here is confusing.

[rphair]

@Quantumplation we decided to put this at Last Check today & merge no later than the next meeting.

I do believe you should incorporate @Ryun1's #556 (comment) or equivalent language before merge, so this section doesn't cause ambiguities later.

[Quantumplation]

@rphair when is the next call? I can promise to have the final draft up by then

[rphair]

@Quantumplation here you are on the agenda again 🤩 Tuesday 12th December 2023 (4PM UTC)

[Ryun1]

An issue with IPFS is that I believe links are always larger than the max size of metadata URL, that being 64 chars

[rphair]

I was thinking that storing only the IPFS CID would make it fit; it appears to have a maximum length of 45 characters (https://proto.school/anatomy-of-a-cid/06) but nobody seems to offer any guarantee of this, e.g. multiformats/cid#21

[Ryun1]

Good idea!
or I suppose, we could just use the metadata hash field of the anchor for the CID and the metadata URL be used to reference IPFS?

[rphair]

The Algorand people were thinking of something like that: https://forum.algorand.org/t/asset-url-max-length-how-to-link-ipfs/3054/3

[Quantumplation]

Is the same restriction being applied to the anchor field? Keep in mind that anchors aren't being stored in the metadata of a transaction, so it might have different restrictions!

[Ryun1]

Yes, this is a limit in the Ledger design... see CDDL here technically 64 bytes I believe.

[Quantumplation]

We might want to ask for that to be raised to support some of the most reasonable likely urls; 64 bytes is pretty limiting!

[Ryun1]

I have raised it internally, not sure why such a limitation was really applied

[Quantumplation]

@Ryun1 @rphair Pushed a final draft ahead of the Tuesday meeting; I think this is in a really good place now, with an example context, example document, etc.

I also folded in your suggestion, @Ryun1, to rename "justification" to "comment".

It's a lot of little pieces swimming, so I'm sure something is misaligned / unclear somewhere, but I think that can be corrected with a follow up PR when it's discovered.

[rphair]

thanks @Quantumplation ... I haven't been able to follow every detail of this proposal but I've been watching every step of the review process and think it represents the best community consensus we might have at this time. So I'm approving in advance of the meeting where it will be Last Check in anticipation of merging at the meeting and officially listing soon after.

[rphair]

p.s @Quantumplation @Ryun1 @Crypto2099 one thing to talk about in the meeting is the "next step" - particularly whether

1. the next planned version of the CIP will fully declare Active status, or if
2. it would be adopted in phases and therefore the Path to Active would be better served with checkboxes than bullet points starting here: https://github.com/Quantumplation/CIPs/blob/master/CIP-0100/README.md#acceptance-criteria