CIP-0100 | Add index and hash to references and allow for basic HTML tags

[Ryun1]

Changes

• Added an index field to the references field.
  • Allowing each reference to be easily be identified.
• Added optional hash to references field.
  • So that references can be optionally cryptographically verified.
• Added the ability for authors to include a HTML tags in their freeform text fields.
  • To allow for authors to highlight bold text, italicised text or code.

cc: @Quantumplation

[Ryun1]

Please people feel free to suggest more :)

Also is HTML the method we want to use, could use the markdown ones like **bold text**.

[Quantumplation]

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?

[rphair]

Also, why HTML over the much more industry standard markdown?

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.

[Quantumplation]

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.

[Ryun1]

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.

This is a good point, id be in favour of adopting this, via CIP-108.

[rphair]

@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.

[Quantumplation]

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?

[Quantumplation]

I think this can be better achieved using the @list keyword on the container: https://www.w3.org/TR/json-ld/#representing-lists-as-arrays

i.e. just express that the references are ordered, and use their natural index.

[Ryun1]

Great idea!

[Ryun1]

might even specify that we use @set keyword, then use something else to reference

[Quantumplation]

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.

[Ryun1]

Make sure to add these to the context and schema.

Will do, but wanted to get confirmation on people's opinion on these changes first.

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.

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.

[Ryun1]

Thinking about it more, with @Quantumplation's insights 🙏

I will move the HTML/Markdown out of this CIP, as they really only apply to longer form text, which is what CIP-108 adds.
This maintains CIP-100 as a barebones standard.

I will keep the suggestion of adding the @list keyword on the references.
But move the additional hashing to CIP-108 and just extend CIP-100 on it.

[Quantumplation]

@Ryun1 I'd also suggest making sure to specify html (or markdown) on a field by field basis; otherwise you end up with like, the authors name having html in it, as that's "free form text" heh

[Ryun1]

@Ryun1 I'd also suggest making sure to specify html (or markdown) on a field by field basis; otherwise you end up with like, the authors name having html in it, as that's "free form text" heh

Good call!

[Ryun1]

For ease, I am just going to add these additions via CIP-108
So I will close this for now