💡 Writing CIP119 metadata for DRep registration and DRep Updates

[Ryun1]

Area

Delegation Pillar

Is there new design needed?

Not sure

What?

• Support all the CIP119 fields for DReps registering and updating their metadata

Why?

• GovTool should be following the appropriate standards

How?

• New designs needed for DRep registration/updating form
• Implement new designs in frontend, with CIP119 metadata template

(Optional) User Story with acceptance criteria

As a DRep
I want to attach rich metadata to my DRep registration
So delegators can have a good understanding of me when looking to delegate

[m-i-k-e]

@Ryun1 is this essential for Bootstrapping, or is it a nice to have feature for this phase?

[m-i-k-e]

To support this, GovTool need to have for DReps"

Ref: CIP 119 - https://developers.cardano.org/docs/governance/cardano-improvement-proposals/cip-0119/

• support for "givenName" - I guess this is the DRep's name that we currently have.
• support for an image - which is a profile photo I guess (how will this be stored?) It's messy as metadata, for sure
• support for checking the hash of the image - If it's included in the metadata json, then the hash for the JSON would suffice
• an optional field for DRep's objectives (freeform)
• an optional field for DRep's motiviations (freeform)
• an optional field for Drep's qualifications (freeform)
• an optional field for DRep's references (type, label, URi) type can be link or "Identity" (not exactly sure what the CIP is stating here)
• optional switch for "do not list" to keep 'private' the info that the DRep has entered from tools like GovTool

Hence, there is some design work, but also we need to understand:

• How we are going to ask users to store 'metadata' images - could this be encapsulated in the JSON file?
• I at least need to further understand what the references fields are about.

[Ryun1]

Hey @m-i-k-e

support for an image - which is a profile photo I guess (how will this be stored?) It's messy as metadata, for sure

For this, GovTool can just support base64 encoding the images
So at DRep registration time, DReps can upload a profile image,
GovTool will then base64 encode it and add it into the JSON file

an optional field for DRep's references (type, label, URi) type can be link or "Identity" (not exactly sure what the CIP is stating here)

This identity thing is weird and confusing, agreed.

For this we can just reuse the links that GovTool already supports in DRep registration.
But add an option for DReps to label a link as identity.

optional switch for "do not list" to keep 'private' the info that the DRep has entered from tools like GovTool

This is a boolean, that I think GovTool should support and enter a default value of False.
This field gives DReps a way to attach metadata to their registration, but without their metdata being listed within DRep directories.

[m-i-k-e]

For this, GovTool can just support base64 encoding the images
So at DRep registration time, DReps can upload a profile image,
GovTool will then base64 encode it and add it into the JSON file

Awesome, just how it should work

[m-i-k-e]

From the CIP:

If the imageObject DOES NOT contain a base64 encoded image, the contentUrl MUST contain the URL where the image can be found and the sha256 property MUST be populated with the SHA256 hash of the image file contents found at the contentUrl. The SHA256 hash is needed in order for readers to verify that the image has not been altered since the metadata anchor was submitted on-chain.

So this means that an image is required, and as far as I understand there can be a url for metadata (along with a hash), and a url for the image (along with it's own hash)

However, to maintain sanity, GovTool will only support writing the image into the single JSON file.

What concerns me is that the image is required. I guess we upload a generic avatar for everyone, and they change it or not.

[Ryun1]

For now, lets not support image upload