CIP-0100 | Add index and hash to references and allow for basic HTML tags
#748
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -162,6 +162,16 @@ We expect a rich ecosystem of CIPs to emerge defining different extensions, so t | |
|
|
||
| The rest of this document will provide a high level description of how these fields should be interpreted | ||
|
|
||
| ### HTML Tags | ||
|
|
||
| For downstream tooling we define a reduced supported set of HTML tags which can be included in freefrom text fields. | ||
|
|
||
| | Tag | Description | | ||
| | --- | ----------- | | ||
| | `<b>` | bold | | ||
| | `<i>` | italicized | | ||
| | `<code>` | code | | ||
|
|
||
| ### High level description | ||
|
|
||
| The following properties are considered common to all types of transactions, and the minimal set needed for "minimum viable governance": | ||
|
|
@@ -180,8 +190,12 @@ The following properties are considered common to all types of transactions, and | |
| - `references` | ||
| - An array of objects | ||
| - Each object specifies a `@type`, which is either "GovernanceMetadata" or "Other" | ||
| - Each object specifies a unique integer `index` field value which increases without gaps from `0`. This is to act as a unique referable ID which can be mentioned in via other fields | ||
|
There was a problem hiding this comment. I think this can be better achieved using the i.e. just express that the There was a problem hiding this comment. might even specify that we use |
||
| - Each object specifies a `label`, which serves as a human readable display name | ||
| - Each object specifies a `uri`; when the type is set to "GovernanceMetadata", the URI should point to another CIP-0100 compliant document | ||
| - Each object MAY have a OPTIONAL `uriHash` object. | ||
|
There was a problem hiding this comment. Make sure to add these to the context and schema. We should also define a time where we're cutting off all further changes (barring mistakes / errors) to CIP-100; This could be a separate CIP which defines the context for this addition, for example, that was the whole point of using JSON-LD. There was a problem hiding this comment.
Will do, but wanted to get confirmation on people's opinion on these changes first.
Yes, I did only make a PR because I don't believe there are any implementations of CIP-100 yet, so thought id try to sneak in these changes. |
||
| - Each object MUST have a `hashAlgo` field. To indicate what hashing algorithm is being used. | ||
| - Each object MUST have a `hash` field. To show the hash digest of the content at the URI. | ||
| - `comment` | ||
| - Freeform text attached to the metadata; richer structures for justifying the transaction this is attached to is left to future CIPs | ||
| - Tooling authors SHOULD emphasize that these comments represent the *authors* views, and may contain bias. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please people feel free to suggest more :)
Also is HTML the method we want to use, could use the markdown ones like
**bold text**.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of incorporating this into the base CIP, shouldn't this be an extension that redefines these fields as able to support HTML?
If it's just what's allowed, then free-form text already allowed HTML; if it's what we expect tooling to support in some way order to be compliant, then this is lifting the lowest common denominator of what tools can be built.
Whereas the whole point of the context was for feature negotiation; a very minimal metadata browser, for example, might just show raw text, and fall back to showing raw data for any fields it doesn't recognize.
Also, why HTML over the much more industry standard markdown?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one justification: because there is one convergent definition of HTML while the "industry standard" of Markdown has produced a bunch of flavours with irreconcilable special features. Those special features in Markdown come from special symbol behaviour, while HTML is always delineated with tag symbols which can be specifically whitelisted herein.
Generally (and maybe even more relevant for blockchain histories), if I had to produce a richly formatted document to go into a time capsule to be readable and/or parseable in 100 years I would rather it be in HTML than any other format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't actually feel that that's the case, except in some extreme niche features; for the most part, people have standardized on github flavored markdown.
The reason I'd argue for GHMD over html, is that it's a lot easier for someone (especially non-technical users) to write in a textbox, and it's also a lot less confusing to read if you're looking at the raw data without the formatting applied.
Even if you know nothing about markdown, asterisks around a word are pretty intuitively indicative of emphasis, while
<b>Some word</b>could be confusing to someone very non-technical.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good point, id be in favour of adopting this, via CIP-108.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Ryun1 @Quantumplation yes, Markdown in hindsight I do think would be better. I was thinking last night in terms of generality but today in terms of failure modes... mainly what happens if the markup isn't rendered. As also suggested in #748 (comment) the non-rendered Markdown is more readable than non-rendered HTML.