When does contentious review happen in Core EIPs?

I agree pretty strongly with this. We need workable governance. I made a proposal for one way to do that here:

@AlexeyAkhunov raises a very valid point that anyone in the decision maker’s seat is potentially opening themselves up to legal liability. So I think we also need to work closely with legal counsel to make sure we have institutional structures in place to protect the decision makers.

I’m not sure I agree with this, and in any case, we should get some legal opinions here. In my opinion it’s less about decentralization (which was more of an issue with the SEC weighing on whether ETH was a security) and more about making sure we have the right legal structures and protections.

We have at least two resources we can turn to in order to figure this out. One is EF, the other is COALA. I’ll begin a dialog on this question with both. Frankly I’m not sure the Magicians is the right forum to discuss legal questions. But I want to include others in the conversation, so we should figure out which forum is the right one.

1 Like

I think organizing stakeholders in a heirarchical way is an effective balance between up-front decision making and “the veil of decentralization”. It is anonymity in a group, you identify with particular group(s) of stakeholders and (if that group is sufficiently large) you can’t be held personally accountable for the decisions of the group (as long as your decision is not broadcasted).

Treeing up to an organizing layer like the Magicians (organized through Rings) would be an effective way to funnel this conversation from it’s most broad to narrow enough to advise Core Devs on the implementation of a proposal.

That, or we just go full politics and elect a rotating body of “trusted community members” at a 1 year interval to advise the Core Devs of community sentiment in any contentious decision. Very similar to @AFDudley’s quip about political whips.

1 Like

Small preface - I’m writing as an individual here as I’ve decided to part ways with Truffle. These words/opinions are my own.

Just wanted to mention EIP-1193 (provider API standardization) as a potential case study for this. @nivida and other devs involved believed in earnest that they’d reached consensus and released a change to web3.js based on the draft EIP as web3.js@1.0.0-beta.38. Unfortunately some fairly significant parts of the development tooling ecosystem (myself included, at the time) weren’t aware that this change was coming and only learned of it when our users (Dapp developers) complained that web3 was erroring when initialized with providers that hadn’t yet been updated for the change.

This issue is water under the bridge as far as I’m concerned (major appreciation to @nivida for this!), but I think it’s worth looking at in a retrospective context as a case where contentious review happened after the point at which the lack of such review would impact the community, and a case where unknown unknowns (e.g. how providers are used by web3, who produces these providers, and how much of the community consumes them) caused a fairly significant disruption to the development community.

1 Like

So a lot of JSON-RPC layer is not considered a Core EIP — it doesn’t affect consensus.

Of course — it’s extremely Core for Dapp developers!

I think this is a perfect example of where having all the stakeholders in JSON-RPC — from tooling to wallets to dapp devs — come together and be an expert group around this.

The OASIS process is suggesting starting with JSON-RPC OASIS-EIP stewarding process


Interestingly EIP-1193 wasn’t even a JSON-RPC concern. It’s defining a standard for an application level concern that pertains only to JavaScript Dapp clients.