Governance of Communities

in #communities4 months ago (edited)

The current features of Communities on HIVE feels to me very much like a pre-alpha release. I shouldn’t be too harsh because even if it’s just a baby step, it’s a step in the right direction and the first step is always the hardest to get right. However, in response to the challenge thrown out by @guiltyparties HERE I thought I’d have a go at outlining a few ideas that might take things further in a direction that might be consistent with the ideals I believe that HIVE (and its communities) should be embracing.


Specifically I am talking about the ideals of Decentralisation and Democratised Governance. To be even more direct, lets just call it Decentralised Governance. To me it makes no sense to have crypto tech with a main benefit and drive of being decentralised and democratised….yet with a centralised form of governance such as we have now with communities. The way it works now an individual creates a community and then effectively “Owns” it, subsequently appointing Administrators (Moderators) who then accept Members in very top-down hierarchical manner. It is almost the exact opposite of how it should be ideally but I do understand that any new community probably needs to start out that way.

So my suggested improvements involve adding features and even a kind of road-map for communities that can see them become, more definitively – Decentralised Autonomous Organisations (DAOs). There is a lot of talk on this platform about creating and supporting DApps, but not so much about DAOs….even though it would be far easier for us to find a niche becoming a preferred DAO platform rather than a DApp platform because of our network effect and the progress made to date, but I digress.

Here are 3 suggestions, perhaps even 3 steps towards making Communities into true DAOs :-

1. Constitutional Settings on the Genesis Account

I really don’t like the term “Owner” when it comes to communities so I will call it the Genesis Account from this point. Basically the creation of a community starts with a Genesis Account and there is already some special “Community Settings” associated with this account. I suggest extending this in the form of what I call “Constitutional Settings” such as NumberOfModerators for the community, ProbationTime for new members before they can vote, VoteExpiryTime for governance votes to expire so that in-actives can’t effectively “brick” the community, GovernanceMode which starts out in Hierarchical Mode (as it is now) but can change to Caretaker Mode or Autonomous Mode as the community matures. The reasons for these settings becomes apparent for #2 and #3 below.

2. Democratic Election of Moderators

Once the community has matured enough, the creator who is operating the Genesis account can change the GovernanceMode setting to Caretaker Mode whereby Moderators are no longer appointed by the Genesis Account, but are instead elected by the Members of the community. One vote per Member – just like any decent democracy should be. Voting could be conducted similarly to the current election of witnesses. Have a look at the NumberOfModerators and that’s how many votes you get if you have been a member longer than the ProbationTime. Here the creator still holds control of the Genesis Account and therefore maintains control of the constitution. They are the “Caretaker” of the community but the community can otherwise appoint Members and elect Moderators autonomously.

3. Multi-Sig Genesis Account

As the community matures further the Caretaker can pass on the Genesis Account to the Moderators by changing the GovernanceMode to Autonomous Mode. Now the creator loses control of the Genesis Account (and the Community Constitutional Settings) and the Genesis account is then managed by the Moderators. Once again, just like real world democracy the Moderators might need a 2/3rds majority amongst themselves to change the Constitutional Settings and that is why the Genesis Account would then need to become a Multi-Signature account. At this point the community can then accumulate assets which would be controlled by the Genesis Account yet with democratic safeguards in place to protect the community assets from misappropriation.

It might sound a bit pie-in-the-sky but changes of this type could be implemented gradually and communities would have a roadmap from being purely top-down Heirarchical with a Centralised Authoritarian Power Structure, to becoming a bottom-up and truly Decentralised Autonomous Organisation.

If you want to participate in the Community challenge then here are the rules :-

1. Write a post listing your top 3 improvement ideas for communities
2. Tag 3 friends in your post who you want to challenge + copy these rules into your post
3. Go back HERE and link your post in the comments

I’m going to go ahead and tag @welshstacker, @summertooth and @silversaver888 who are all members of my favourite community who have shown an interest, and willingness to wade into the conversation about communities in the past.


In hindsight I really should have tagged @lukestokes on this as he's been involved with EOSDAC that might have some overlap.

Some good thoughts here, for sure. I think some structure is needed, just as our bodies have cells which create organs which have different purposes, roles, responsibilities, etc. A governing body of leadership makes sense over a completely flat hierarchy which would be like a body made up entirely of stomach cells instead of different cells (like brain cells, etc) performing different roles. Any 1 account, 1 vote approach can fail to a sybil attack. At least with communities, people are free to create their own competing community, though it hinders the network effect for that topic.

Thanks for dropping in!

Sybil attacks are possible in real world democratic institutions. I believe it's typically referred to as "Branch Stacking" in the political sphere.

The idea here is that Moderators can validate/identify Members however they please and the ProbationTime setting prevents a Moderator from stacking his community (a sybil attack) without giving the other Mods (and Members) time to counter the attempt.

It's not perfect but this implementation would be a relatively simple way of introducing a few checks and balances.