Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hash should be the *ip preamble #9

Closed
BelfordZ opened this issue Mar 12, 2019 · 12 comments · Fixed by #10
Closed

Hash should be the *ip preamble #9

BelfordZ opened this issue Mar 12, 2019 · 12 comments · Fixed by #10
Assignees
Labels
bug Something isn't working

Comments

@BelfordZ
Copy link
Owner

image

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

@BelfordZ BelfordZ added the bug Something isn't working label Mar 12, 2019
@BelfordZ BelfordZ self-assigned this Mar 12, 2019
BelfordZ added a commit that referenced this issue Mar 12, 2019
@whilei
Copy link

whilei commented Mar 12, 2019

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

@whilei
Copy link

whilei commented Mar 12, 2019

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
Copy link

whilei commented Mar 12, 2019

So for example the preamble could be

Title: Byzantium on block 696969
Author: Santa Clause <[email protected]>
Discussions-To: [email protected]
Status: Draft
Type: Standards Track
Created: 2020-05-25
Replaces: e0c214e23b458ee5efeb53aebe632b70ae2d4ed3c682775e674eef5939f2d2d740c3b0199d40d08bb1b943862b27f0d8977fd43d0cde711d02d3a3b1b9616b8a
Superseded-By: 799c8bd30186f2dcfd7c8ef67d36a4b9f3c1ff73d3a7d4df4cf1808bde9d4cde3d19f441425782b3d1465757520af51ffa93eccb25f9074dc304226f81ebd96c
    Title: Byzantium on block 696969
    Author: Santa Clause <[email protected]>
    Discussions-To: [email protected]
    Status: Draft
    Type: Standards Track
    Created: 2020-05-25
    Replaces: e0c214e23b458ee5efeb53aebe632b70ae2d4ed3c682775e674eef5939f2d2d740c3b0199d40d08bb1b943862b27f0d8977fd43d0cde711d02d3a3b1b9616b8a
    Superseded-By: 799c8bd30186f2dcfd7c8ef67d36a4b9f3c1ff73d3a7d4df4cf1808bde9d4cde3d19f441425782b3d1465757520af51ffa93eccb25f9074dc304226f81ebd96c
---
Title: Byzantium on block 696969
Author: Santa Clause <[email protected]>
Discussions-To: [email protected]
Status: Draft
Type: Standards Track
Created: 2020-05-25
Replaces: e0c214e23b458ee5efeb53aebe632b70ae2d4ed3c682775e674eef5939f2d2d740c3b0199d40d08bb1b943862b27f0d8977fd43d0cde711d02d3a3b1b9616b8a
Superseded-By: 799c8bd30186f2dcfd7c8ef67d36a4b9f3c1ff73d3a7d4df4cf1808bde9d4cde3d19f441425782b3d1465757520af51ffa93eccb25f9074dc304226f81ebd96c
---

yea?

@ghost
Copy link

ghost commented Mar 13, 2019

[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 ghost closed this as completed Mar 13, 2019
@ghost
Copy link

ghost commented Mar 13, 2019

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

@ghost ghost reopened this Mar 13, 2019
@phyro
Copy link
Collaborator

phyro commented Mar 13, 2019

agree with @whilei , consistent format is crucial for hashes

@YazzyYaz
Copy link
Collaborator

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
Copy link

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
Copy link

ghost commented Mar 13, 2019

If this is a good solution, I propose from

{teamName}-{root}-{number}

to

{root}-{teamName}-{number}

like

ECIP-Belfordz-1234

@BelfordZ
Copy link
Owner Author

BelfordZ commented Mar 13, 2019

@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
Copy link
Collaborator

@BelfordZ Will make a ticket for sure!

@phyro
Copy link
Collaborator

phyro commented Mar 13, 2019

@YazzyYaz there were some good points made against having a machine format on a different issue #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants