Ethereum Classic (ETC): Decentralized ECIP Chat on Discord on 3/22/2019 at 12 EST – Recap

Today we conducted a voice call in the Ethereum Classic ecosystem about a new Decentralized ECIP Process proposal:

Tweet by Ethereum Classic thanking community participation in the call.

High Level Summary:

The ECIP aggregation site is a good idea (nearly everyone agreed with it).
The proposed Decentralized ECIP process in general is a nice to have, but there are more important things in the short term to focus on, such as the Byzantium hard fork.
The proposed Decentralized ECIP process creates a lot of friction for developers, minimizing its possible adoption, by adding steps and activities on top of their normal work.
Going in small steps: A tool to create standard preambles for decentralized ECIPs will be built to see if developers like it and adopt it (see “Preamble Tool” section below).

Agenda and Feedback:

1. Current situation:
• Migrating from centralized to decentralized ECIPs
• Existing repos:
– ETC community ECIPs
– ETC Labs Core ECIPs
– That.World/Ethoxy Initiative ECIPs

The current situation was described and there were no major objections in the general discussion. A few days before this call ETC Labs Core had changed its improvement proposal name from “ECLIPs”, a name that caused controversy, to “ECIPs” (see here), which was well received as an indication that they wish to follow ecosystem standards.

It was, however, brought by some participants in the text chat during the call that the Byzantium hard fork seems a more pressing matter and that perhaps that would have been a higher priority than the Decentralized ECIP process:

“I’m also not sure if we need this right now e.g. I’d prefer this talk was about byzantium changes”
“Same.”
“yes, let’s talk Byzantium”
“It’s an interesting problem to think and discuss but we should prioritize stuff”
“Our time is pretty much up though”
“happy to help there if it means we can focus on more important stuff”
“We need to talk about that while we’re all here”
“next Friday call maybe, need to drop for my next meeting”

2. Goals: To agree on a standard process. To have all teams and individual devs use it (e.g. the above + Parity + IOHK + independent developers).

The goals of the Decentralized ECIP process were presented. There is general agreement about having “a system”, but there were some objections in the general discussion around having the freedom to use or not specific tools, such as Github, a team web repository, etc.

3. Description: ECIPURI + starIP + ECIP-1000 + Archiving + Model site

• ECIPURI:
– URI formats:
– ecips.teamdomain.tld/ECIP-hash
– github.com/teamname/ECIPs/ECIP-hash
– URI Directories:
– Known directory: standard known.json file
– Specs directory: standard specs.json file (team need to update each new ECIP)

• starIP deterministic numbering
– Standard preamble
– SHA3–512 hash
– Encode in BASE58
– Use last 8 characters as ECIP version number
– Use last 4 characters as ECIP proposal number
– Complete standard preamble with numbers, URIs and discussion URL

• ECIP-1000: a standard process described in 2017

• Archiving: the idea is for all ECIPs “live” in independent archives in case teams shut down, delete them or anything that may happen

• Model site: ecips.that.world

The components of the Decentralized ECIP process were presented. The feedback in the general discussion was that adding steps and new rules for developers to follow may create friction that, in the end, may discourage adoption of the new system:

• “yeah KISS method :)”

4. Invite creators to describe their proposal: Wei (ECIPURI + ECIP-1000 + model site), Zach/Shane (startIP), Tomasz Zdybal (Archiving)

Wei Tang and Tomasz Zdybał were not present to describe the components they created (ECIPURI and Archiving respectively), but Zachary Belford explained the StarIP Standard along the argument that in a federated system with several teams writing ECIPs in different repos, it is necessary to have a standard deterministic numbering system. There was general agreement:

“yeah the starip distributes the control over the processes instead of one repo”

5. Open discussion: Questions & answers

After the introduction and explanation by Zach Belford, Zac Mittonexpressed that it is ideal to have aggregation and the the ideas presented, but he felt that the additional friction brought on developers may discourage adoption of the Decentralized ECIP. There was general agreement by various participants.

A user by the handle DBamford explained that from his outsider view he thought that ETC seems to be going through a lot of chaos and that he thinks the community should not fear a centralized process (presumably referring to using Github and imitating the BIP and EIP processes). Responses by other participants were that the curent discussions about the ECIP process were not regarded as a threat or “chaos” within ETC. In general there was a an agreement that, eventually, a logical and decentralized process could emerge and that such discussions were actually productive and a signal of true decentralization.

The following are some other questions that were addressed in the call:

1. Where will this ECIP run? Github? Who will be the admins? Or it will be etc chain dependant?

Zach Belford responded that really the underlying tools to implement the ECIP process should not be compulsory, that people can submit an ECIP using Github, their own website, or other means including mailing letters! (the last was a joke, but served as an analogy of the freedom devs should ideally have).

Donald McIntyre expressed his preference that everybody use Github as it is the software versioning platform everybody uses in the world, but there was general agreement about freedom of tools and having no specific set, especially as compared to the systems of Bitcoin-BIP and Ethereum-EIP processes.

2. How does a casual follower get a global view of ECIPs that are active?

Several participants responded that aggregation sites would be a good idea to help casual followers find ECIPs and their discussion locations.

It was commented that Wei tang did a great job creating the aggregation site ecips.this.world as an example of how such aggregation sites could work.

It was also reminded by Anthony Lusardi that the ECIP aggregation site above is actually open source and can be used by anyone to create their own ECIP aggregation site. You can find it here.

The following are some questions that were not addressed, as they were not seen or the call ended, but remain pending:

how do we retain comment history? if you have N repos where there are comments for an ECIP, the probability of one disappearing is higher. Do we care about this or is it a non issue?
I see that our difficulty rn is not the platform or channel of reference but the difficulty of agreement between different entities. So are we gonna fix the github reference to make it more easy to come easier to an agreement?
How are ecips closed/finalized/accepted ? this has always been a bigger issue than discovery for me
im happy with any system as long as it is easy to understand for the casual observer. ethereumclassic.org header process and tracks would be nice. also an infographic on ther explaining it

Comments about the “Preamble Tool”:

As some of the main themes of the chat were to “keep it simple” and “start small” to see if developers would start adopting new decentralized standards for the ECIP process, there was general agreement to build in the ETC Cooperative and/or the ethereumclassic.org website a tool to easily build ECIP preambles using the standards described in the meeting.

The idea of the tool is that it would convert a basic standard ECIP preamble entry into the full preamble in the following way:

1. You enter:

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: kRau7PZs
Superseded-By: ZxftDmL3

2. And returns:

ECIP: kMre
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
Version: 6z9ekMre
Replaces: kRau7PZs 
Superseded-By: ZxftDmL3
URI: ecips.santaclaus.com/ecip-kmre
Discussion URL: github.com/santaclaus/ecips/ecip-kmre/issues/

Notes, Other Thoughts and Conclusions:

Help create a similar call to talk about the Byzantium hard fork (ECIP-1054).
Anthony Lusardi (ECIP-1047) and Alexander Tsankov (ECIP-1049) should continue to push their ECIPs in the ETC community repo where they originally submitted them.
Biggie is better than Tupac.
“Voting” was commented in the text chat during the call as a solution to agreeing on ecosystem processes, but it was generally rejected.
Zac Mitton expressed that the problem-solution logic should be stated clearly to understand if the Decentralized ECIP process was adequate. Zach Belford agreed and stated that is an important way of proceeding going forward.
There was general agreement that doing these calls are productive when addressing important ecosystem issues.