make gov composable

[tac0turtle]

Summary

Currently x/gov is one large module and it is a governance model forced onto users. Instead we should refactor x/gov to have components that can be composed into a governance module and/or groups module. There can be many things reused across the 2 modules.

Problem Definition

gov is a single model, instead of a composable module for different modules

Proposal

Rewrite gov to have components and can be composed into an application.

[robert-zaremba]

How would that look like? What kind of independent components do you see? Are the components going to be independent Go modules?

[tac0turtle]

I don't think the components need to be in their own go.mods but the gov module today should be the default one provided but applications can provide their own custom logic of tallys and other things to customise gov while keeping proposal and some other things consistent

[hxrts]

Any way you take this, here's an old draft from the gov product WG for reference: https://docs.google.com/document/d/18zmqL1ujCybtHsccw_jTZQFg-_Q77qubtdjlEfQGduo/edit#

[alexanderbez]

I think a DAO-DAO style mechanism would be an interesting thought experiment. I don't know much about how the end product will look like, but I do strongly agree the current module and design is much too rigid for how governance is attempting to be conducted today.

[robert-zaremba]

Maybe, instead of breaking the existing x/gov we should create a new one?
In my opinion x/gov should be solid and well composable with existing messages (as it is now) - and it should be a foundation of the chain governance.

We can have x/dao as an experiment of more elastic governance model, maybe working with groups and dynamic membership (like coin holding).

[julienrbrt]

Maybe, instead of breaking the existing x/gov we should create a new one? In my opinion x/gov should be solid and well composable with existing messages (as it is now) - and it should be a foundation of the chain governance.

We can have x/dao as an experiment of more elastic governance model, maybe working with groups and dynamic membership (like coin holding).

Wasn't the group module supposed to be an alternative to DAO DAO?
ref: https://blog.cosmos.network/secret-powers-what-do-the-upcoming-groups-and-gov-modules-enable-964a22f0a9cd

[alexanderbez]

What I'm getting at here in this context isn't message execution and the general execution model -- but more so the rules around execution, i.e. how and when are proposals executed. This is mainly the core bit of x/gov that is not composable and is too rigid.

[tac0turtle]

I think making gov composable and the default working the same as now is not hard, it would be 2-3 weeks of work to make it happen

[hxrts]

the rules around execution, i.e. how and when are proposals executed. This is mainly the core bit of x/gov that is not composable and is too rigid.

The original idea was to migrate gov to use the decision policy system from groups.

[alexanderbez]

So then based on what @hxrts is saying, is there really anything to do here @tac0turtle?

[tac0turtle]

yes, first we should make components of groups and gov reusable. Meaning there should be a single proposal type, then we should remake gov as a subset of groups meaning that a chain can say they want x and y. Saying groups is a replacement for gov is not sufficient since it's not in the current design. While groups is better there is a little amount of code that can be reused for other things that would allow applications to compose governance or even groups. Right now we have duplicate proposal types, and other types across groups and gov, while making some of these components reusable would reduce the amount of code and clean up the designs

[hxrts]

@ValarDragon what are you feelings about the groups group policy/decision policy architecture? https://github.com/cosmos/cosmos-sdk/tree/main/x/group#concepts

I believe group policies can fulfil most of what you were looking for from typed proposals, no?

[tac0turtle]

what if we made a dao package of reusable types like proposal, tally, etc.. that then is used to compose gov and groups?

(ado package can be called something else )

[julienrbrt]

what if we made a dao package of reusable types like proposal, tally, etc.. that then is used to compose gov and groups?

(ado package can be called something else )

If groups was supposed to be the replacement it makes to have gov import group actually instead of a third package imo.

[tac0turtle]

we can do that, I was thinking groups is one implementation but others could want to do their own.

[aaronc]

Generally agree with the direction of merging gov and group as originally planned. We need to think through how to refactor decision policies to cover gov tallying. That was the part we didn't have bandwidth to align on previously