Reconsider spec design

[jnordberg]

The current spec includes YAML, CommonMark and Handlebars. All of which have large attack surfaces making it very difficult for implementers to create a secure parser and renderer. Considering that many EOSIO wallet applications are written using web technologies (e.g. electron) an XSS usually means that an attacker can export users keys or re-key their accounts. It is also a risk that an attacker could use the rich formatting allowed by this spec to mimic wallet UI elements to trick the user.

Besides the security considerations this design also has the drawback that it is focused only on rendering to HTML and don't translate well when you want render a contract to e.g. a native UI framework or PDF.

I suggest a simplification of the current spec so that it could be turned into a token stream by a rudimentary parser that then can safely be rendered to HTML or other formats.

The metadata could be changed from frontmatter/yaml to a [string key]: [string value] format and the html/markdown + moustache templating contract body could be replaced with plain text + a very small subset of moustache for flow control and variable substitution. Instead of relying on filters like nowrap and to_json the parser can pass along the underlying EOSIO types with the token stream when encountering a variable which would allow rich formatting by the renderer.

You could probably do away with filters altogether and instead define getters on the types in question, e.g. instead of Send {{ amount_from_asset quantity }} of the token {{ asset_to_symbol_code quantity }} you would write Send {{ quantity.amount }} of the token {{ quantity.symbol.code }}

[jnordberg]

CC @nsjames @aaroncox

[pur3miish]

I think that the current spec design is too opinionated.

Why can't we just use JSON.

[mgravitt]

We also strongly support changes to this spec. We would prefer the simplification described by @jnordberg above. Specifically, we are looking to render Ricardian contracts in other native UI frameworks such as Flutter.

What do you think about this? @TaraTritt @esheffield @jeffreyssmith2nd

[pur3miish]

I would like to see something like this.

// ABI transfer action.
{
"ricardian_contract": {
 "spec_version": "0.2.0",
 "title": "Transfer Tokens",
 "summary": "Send {{quantity}} {{from}} from to {{to}}",
 "icon": "http://127.0.0.1/ricardian_assets/eosio.contracts/icons/transfer.png#5dfad0df72772ee1ccc155e670c1d124f5c5122f1d5027565df38b418042d1dd",
 "message": "{{from}} agrees to send {{quantity}} to {{to}}. {{conditional_1}}",
 "conditionals":  {"conditional_1": { "message": "..." }
}

const  args =  [{"from": "accountname1"}, {"memo": ""}, {"quantity": "1.0000 EOS"}, {"to": "accountname2"}]

[jnordberg]

@pur3miish The meat of the spec is in the templating language used for the message, using JSON to encapsulate that or markdown style metadata + text is a minor difference IMO.

And while I think there is some merit in coupling the ricardian spec with the EOSIO ABI spec like your example it would be a breaking change to all existing ABI parsers. To keep it compatible you would need to pass your format as a JSON string and we end up with JSON in JSON.