It can be quite clear to the user what is happening in the groups they subscribe to.
I would like to see/accept this proposal exact as it was titled: a framework.
A framework that is still to be implemented into ready-to-use product, when exact all this can be’s must be provably implemented. Even a framework becomes accepted, an particular implementation must be validated later once more. No implementation of the framework should be accepted automatically just because the underlying framework was accepted.
and once more: any automatically enforcement after some boolean function mapping votes into boolean is dangerous, because it pretend to be safe and trustless, but can be easily forked out. We use word “governance”, but it is a signalling, indeed.
I totally agree, there’s a road map that needs to be executed for this to work. If I had to guess, here’s how it might unfold:
A client team with incentive to encourage a hard fork might implement “accepting on-chain hard fork proposals with client parameters” as a way to make it easier to develop the hard fork, in a community-focused way that gives users the power of choosing future forks in general, not merely supporting their own interests.
Once one client has implemented this, they should advertise their client as the client that gives the user the most control over the fork policy that their client uses, in hopes to either steal users to that client, or pressure other client developers to relinquish their own privileged decision making position by implementing support for the same.
There will probably be a friction period, either where some client devs don’t want to support this feature (either out of conviction or seeing it as a waste of time, since they may not want or need any hard forks), and so it might come down to people who have the most at stake (for example, people hoping for a funds recovery) to fund the development of this general feature for all clients.
If core client developers aren’t interested in supporting user-chosen hard fork policies, and refuse to review/merge these PRs, that might be a good reason to fork those clients, with hopes to merge after the changed version is proven stable.
IMO, any client not favorable to a user configured fork choice rule is entrenching their own power, and informed users should flock away from those clients as other alternatives emerge.
@danfinlay,
working on EIP categorisation, I found myself mentally in a structure similar to “Strange Loop”.
Are you going to Prague to EthM Gathering? Would be great to discuss more details.
Would be great to chat about this at DevCon @danfinlay. This seems to be highly applicable in a very general sense to governance research we’ve been working on at Facebook and I’d love to share vision. Thank you for putting this together, hope to meet you soon.