BelfordZ / starIPs

The * Improvement Proposal repository.
Apache License 2.0
6 stars 0 forks source link

Linter and Validator for Preamble #14

Closed YazzyYaz closed 4 years ago

YazzyYaz commented 5 years ago

If we are going to hash the preamble, then it must follow a consistent structure prior to being hashed.

In order to do that, we need to account for users adding whitespaces, typos, wrong options on some of the preamble categories, all which leads to generating the wrong hash if they try to verify it.

This can be done via a script. For simplicity, we can propose users write out a YAML file (it has least amount of spaces involved and is super easy to write).

1) Our verification script must first lint the YAML file to ensure there's no white spaces or space between preamble categories. 2) It must then ensure the preamble categories are in the correct specified order. 3) It must then verify that for some of the categories which provide a set of options, the option selected by the user has no typos and matches what is allowed to be entered. 4) It must also ensure the datetime format submitted in the date category of the preamble adhere to the specification outlined.

It can easily be done via a command-line script. Sorta like a preamble & hash generator.

$ starip init
Welcome to the StarIP Specification Generator!
Enter a name for your StarIP:

This ensure lesser mistakes on user part and easy to do. It will then generate the hash, YAML file and human-readable number.

Can then be extended to a website for better UI, but that's trivial if we get the script going first.

ghost commented 5 years ago

Devs would go to this website, fill a form, and then the website would give them a preamble in a YAML format with the hash + version + human-readable number? Then they paste that into the ECIP as the preamble?

YazzyYaz commented 5 years ago

Exactly.

This minimizes errors because, let's say User A wants to define the type of starIP:

We can see here that the user made a type when writing Core, so that gets used in the preamble to generate the hash.

If User B wants to generate the same hash after, they can't because they'd enter Core when they should've entered the type Coer like User A.

By having a helpful script + a website for generation, we can provide strict options for them to use for type from a drop down menu that minimizes typos since a user just clicks on the type they want.

After that, it generates the hash and a reference preamble for the user that they can use to regenerate the hash after. It will also provide the human-readable number.

After that, yes they can paste the preamble inside the YAML file to the ECIP document they are creating.

phyro commented 5 years ago

I'll echo what I said on the previous issue. @YazzyYaz I think this is a good idea, but it introduces quite some work (validation and website). I believe that both YAML and JSON spec don't guarantee the order of the elements (https://stackoverflow.com/questions/13297744/pyyaml-control-ordering-of-items-called-by-yaml-load). I'd still support JSON format over YAML because it is a format that is much more used for communication e.g. node clients communicate in json and similarly the discovery mechanism from Wei does too. The specs.js from Wei could be a collection of preambles:

[{
  "preamble": {...},
  "starIP-full": "http://stars.com/ip1/ip1_smth_d3fg1c90.json"
  "starIP-link": "http://stars.com/ip1",
}, {
  "preamble": {...},
  "starIP-full": "http://galaxy1.com/ip3/ip3_blabla_d3fg1c90.json"
  "starIP-link": "http://galaxy1.com/ip3",
}]

While it is something I'd personally want to move towards and have at some point, it goes perhaps against the idea of making small changes - unless we want to make a huge change at once and say that this is how the IPs should be. I'm not really sure what the idea around this is, was that meant to be an experiment that gets improved over time or a one time change?

YazzyYaz commented 5 years ago

https://github.com/ethereum-classic-cooperative/starip-preamble-generator