Hash should be the *ip preamble

[BelfordZ]

except we must remove ECIP number cause that part woul;dnt make sense

[whilei]

Why not everything except the preamble, as discussed in #5?

[whilei]

Typically in the documents this metadata is specially formatted, either as a code-fenced block or (maybe somewhere I've seen...) ~a like one of those blog/Jekyll tag header type thing going on~ front-matter.

I guess we'll also need a spec for how this is formatted exactly? At for least for where the "preamble" starts and stops. Because I don't want to accidentally include an extra tab, newline, --- or whatever if I'm trying to get or confirm a hash.

[whilei]

So for example the preamble could be

Title: Byzantium on block 696969
Author: Santa Clause <a@b.c>
Discussions-To: a@b.c
Status: Draft
Type: Standards Track
Created: 2020-05-25
Replaces: e0c214e23b458ee5efeb53aebe632b70ae2d4ed3c682775e674eef5939f2d2d740c3b0199d40d08bb1b943862b27f0d8977fd43d0cde711d02d3a3b1b9616b8a
Superseded-By: 799c8bd30186f2dcfd7c8ef67d36a4b9f3c1ff73d3a7d4df4cf1808bde9d4cde3d19f441425782b3d1465757520af51ffa93eccb25f9074dc304226f81ebd96c

    Title: Byzantium on block 696969
    Author: Santa Clause <a@b.c>
    Discussions-To: a@b.c
    Status: Draft
    Type: Standards Track
    Created: 2020-05-25
    Replaces: e0c214e23b458ee5efeb53aebe632b70ae2d4ed3c682775e674eef5939f2d2d740c3b0199d40d08bb1b943862b27f0d8977fd43d0cde711d02d3a3b1b9616b8a
    Superseded-By: 799c8bd30186f2dcfd7c8ef67d36a4b9f3c1ff73d3a7d4df4cf1808bde9d4cde3d19f441425782b3d1465757520af51ffa93eccb25f9074dc304226f81ebd96c

---
Title: Byzantium on block 696969
Author: Santa Clause <a@b.c>
Discussions-To: a@b.c
Status: Draft
Type: Standards Track
Created: 2020-05-25
Replaces: e0c214e23b458ee5efeb53aebe632b70ae2d4ed3c682775e674eef5939f2d2d740c3b0199d40d08bb1b943862b27f0d8977fd43d0cde711d02d3a3b1b9616b8a
Superseded-By: 799c8bd30186f2dcfd7c8ef67d36a4b9f3c1ff73d3a7d4df4cf1808bde9d4cde3d19f441425782b3d1465757520af51ffa93eccb25f9074dc304226f81ebd96c
---

yea?

[ghost]

[brought this from #10]

Hi @whilei the idea of the startIP system is to create a deterministic numbering so that all ECIPs can be decentralized in different repos, but with a common standard.

These are examples of centralized preambles in BIP, EIP, ECIP:

BIP:

 BIP: <BIP number, or "?" before being assigned>
* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
  Title: <BIP title; maximum 44 characters>
  Author: <list of authors' real names and email addrs>
* Discussions-To: <email address>
* Comments-Summary: <summary tone>
  Comments-URI: <links to wiki page for comments>
  Status: <Draft | Active | Proposed | Deferred | Rejected |
           Withdrawn | Final | Replaced | Obsolete>
  Type: <Standards Track | Informational | Process>
  Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
  License: <abbreviation for approved license(s)>
* License-Code: <abbreviation for code under different approved license(s)>
* Post-History: <dates of postings to bitcoin mailing list, or link to thread in mailing list archive>
* Requires: <BIP number(s)>
* Replaces: <BIP number>
* Superseded-By: <BIP number>

EIP:

eip: (this is determined by the EIP editor)
title:
author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.>
* discussions-to: <a url pointing to the official discussion thread>
status: <Draft | Last Call | Accepted | Final | Active | Deferred | Rejected | Superseded>
* review-period-end:
type: <Standards Track (Core, Networking, Interface, ERC) | Informational | Meta>
* category: <Core | Networking | Interface | ERC>
created:
* updated:
* requires: <EIP number(s)>
* replaces: <EIP number(s)>
* superseded-by: <EIP number(s)>
* resolution: <a url pointing to the resolution of this EIP>

ECIP:

 ECIP: <ECIP number>
  Title: <ECIP title>
  Author: <list of authors' real names and optionally, email address>
* Discussions-To: <email address>
  Status: <Draft | Active | Accepted | Deferred | Rejected |
           Withdrawn | Final | Superseded>
  Type: <Standards Track | Informational  Meta>
  Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
* Replaces: <ECIP number>
* Superseded-By: <ECIP number>
* Resolution: <url>

[ghost]

closed this issue by mistake...sorry! re-opened!

[phyro]

agree with @whilei , consistent format is crucial for hashes

[YazzyYaz]

What if we use a specific JSON format and we have a script here that automatically lints it and checks if the order is in a correct format. We can then include the lint and validator script for the preamble as part of the starIP package that people would need to fork.

Lint takes care of whitespace issues and ensures correct formatting and tab space.

We can even simplify it as a YAML file:

title: <starIP Title>
author: <starIP Author>
discussions-to: <a url pointing to the official discussion thread>
status: <Draft | Last Call | Accepted | Final | Active | Deferred | Rejected | Superseded>
type: <Standards Track (Core, Networking, Interface, ERC) | Informational | Meta>
created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
replaces: <starIP number(s)>
superseded-by: <starIP number(s)>
resolution: <a url pointing to the resolution of this EIP>

[meowsbits]

what if instead of ECIP-1234 style, so with just the ECIP, what if it were like BelfordZ/ECIP-1234 or whatever? so we can support forks, describe the source of a proposal, and solve a part of the numbering/id problem the same time?

[ghost]

If this is a good solution, I propose from

{teamName}-{root}-{number}

to

{root}-{teamName}-{number}

like

ECIP-Belfordz-1234

[BelfordZ]

@meowsbits 1. I do like the idea of the 'front matter' as the name. It was suggested to call it the preamble.

As for formatting, I suggest we add to this repo some restriction or preprocessing of the preamble that is required. In this specific case, we can say that all leading and trailing whitespace surrounding a line in the preamble MUST be removed.

@YazzyYaz linting tool sounds good to me. Can you make a ticket and describe the work in there? Having a --fix parameter, similar to other linters would be nice :).

@meowsbits that would certainly work, though I think this is a layer above what we are proposing / the scope of this repo.

We are only suggesting a deterministic versioning scheme and numbering scheme, as well as a name that should be generic enough for any project. That being said, I think there is lots of opportunity to wrap the name in any kind of other spec, as @sorpaas has done in his ecip 24. I'm thinking simplest and smallest change is best. This allows for the many things to be tried, experimented with, and added only if absolutely necessary.

[YazzyYaz]

@BelfordZ Will make a ticket for sure!

[phyro]

@YazzyYaz there were some good points made against having a machine format on a different issue https://github.com/BelfordZ/starIPs/issues/5 . I also think it's good not to drop a bomb on people by changing too many things at once, especially not making them write in some formatted syntax (although I'd totally support the json format if there was a subproject in IP repository that was a website with input fields for each preamble entry and a live markdown preview with a button to generate the IP json). But this brings additional work. That said, I totally support the linter for the plain text format and we can then transform it to our own formats if we want to (yaml, json,..) and share them via ecipuri network or similar.