"Communities" pallet

[olanod]

Communities Pallet

Part of the People Local Interactions Protocol, this pallet enables people
to unite and create local communities that share a common interest or
economic activity. In simpler terms, it can be considered a DAO Factory.

Overview

The Communities pallet provides functionality for managing communities,
facilitating its participants to have governance over the community entity
(and its associated account), and running economic activities:

• Community registration and "removal". #292
• Enrolling/removing members from a community. #296
• Handling a community-governed treasury account #295
• [Communities] Promoting/demoting members within the community #323
• [Community] Implement Governance #303
• [Community] Validating a community challenge. #294

Terminology

• Community: An entity comprised of members —each one defined by their
  AccountId— with a given description who can vote on proposals
  and actively take decisions on behalf of it. Communities are given a
  treasury account and can issue governance and economic tokens. It is
  required that a community contributes to the network to be active and
  operate within it.
• Community Description: A set of metadata used to identify a community
  distinctively. Typically, a name, a list of locations (given as a list of
  one or more H3Index), and a list of URL links.
• Community Status: A community can be either awaiting, active, or
  frozen depending on whether the community has proven via a challenge
  it's actively contributing to the network with infrastructure provisioning
  (i.e. a collator node) or by depositing funds.
• Validity Challenge: A proof that a community is actively contributing
  to the network. The mechanisms for challenge verification are usually
  checked via an off-chain worker. Still, it's possible for a trusted origin
  to manually mark a community challenge as passed, effectively changing the
  status of the community to active.
• Admin: An AccountId registered into the community that is set
  as such. Can call privileged functions within the
  community.
• Member: An AccountId registered into the community as such. Can
  have a rank within it and vote in the community's polls.
• Member Rank: Members could have a rank within the community. This can
  determine a voting weight depending on the community's voting mechanism.
• Proposal: A poll with an optionally set duration that executes a
  call dispatch if approved when it's closed.
• Treasury Account: A keyless AccountId generated on behalf of
  the community. Can receive payments, transfers, or payment fees.
  It can transfer funds via a privileged call executed by the community
  admin or a call dispatched from a proposal.
• Community Token: A fungible asset issued and
  administered by the Treasury Account of the community. It might be used to
  vote if set via voting method. Also, it can be marked as sufficient.
• Voting Method: Can be either rank or asset and determines how the
  votes of proposals will be tallied.

Goals

The "communities" are designed to facilitate the following use cases:

• Enable entities (i.e. DAOs) or local-bound groups of people (physical
  communities) that share common interests to create markets.
• Allow communities can receive taxes (as in payment fees) and be
  self-sustainable.
• Let such communities to sovereignly decide how to spend those gathered
  funds by running and voting on proposals.

Lifecycle

[       ] --> [Awaiting]              --> [Active]            --> [Frozen]      --> [Blocked]
apply         set_metadata                set_metadata            set_metadata      unblock
              fulfill_challenge           block                   block
              force_complete_challenge    add_member              thaw
                                          remove_member
                                          promote_member
                                          demote_member
                                          issue_token
                                          open_proposal
                                          vote_proposal
                                          close_proposal
                                          assets_transfer
                                          balance_transfer
                                          set_admin
                                          set_voting_mechanism
                                          set_sufficient_asset
                                          freeze

Implementations

TODO: Define which traits we are defining/implementing.

Interface

Permissionless Functions

• apply: Registers an appliation as a new community, taking an
  existential deposit used to create the community account.

Permissioned Functions

Calling these functions requires being a member of the community.

• fulfill_challenge: Submit the challenge proof to validate the
  contribution status of the community.
• add_member: Enroll an account as a community member. In theory,
  any community member should be able to add a member. However, this can be
  changed to ensure it is a privileged function.
• open_proposal: Creates a proposal to be voted by the community. At
  this point, there can only be a single proposal at a time.
• vote_proposal: Adds a vote into a community proposal.

Privileged Functions

These functions can be called either by the community admin or
dispatched through an approved proposal. !

• set_metadata: Sets some CommunityMetadata to describe
  the community.
• remove_member: Removes an account as a community member. While
  enrolling a member into the community can be an action taken by any
  member, the decision to remove a member should not be taken arbitrarily by
  any community member. Also, it shouldn't be possible to arbitrarily remove
  the community admin, as some privileged calls would be impossible execute
  thereafter.
• promote_member: Increases the rank of a member in the community. ! -
  demote_member: Decreases the rank of a member in the community.
• issue_token: Creates a token that is either governance (only one per
  community allowed) or economic. While the first economic token is
  "free"," further ones would be subject to network-wide referenda.
• close_proposal: Forcefully closes a proposal, dispatching the call when
  approved.
• assets_transfer: Transfers an amount of a given asset from the treasury
  account to a beneficiary.
• balance_transfer: Transfers funds from the treasury account to a
  beneficiary.
• set_sufficient_asset: Marks an asset issued by the community as
  sufficient. Only one asset at a time can be marked as such.
• set_admin: Sets an AccountId of the admin of the community.
  Ensures that the specified account is a member of the community.
• set_voting_mechanism: Transfers funds from the treasury account to a
  beneficiary.

Root Functions

• force_complete_challenge: Marks a challenge as passed. This can lead to
  the activation of a community if all challenges are passed.
• block: Sets a community status as blocked, specifiying a reason for the blocking.
• unblock: Sets a community status back to the previously given state.

Public Functions

• community: Stores the basic information of the community. If a value exists for a
  specified ComumunityId, this means a community exists.
• metadata: Stores the metadata regarding a community.
• member_information: Stores the information of a community (specified by its
  CommunityId) member (specified by it's AccountId).
• members_count: Store the count of community members. This simplifies the process of keeping track of members' count.

Related Issues

• Community registration #133
• User enrollment/upgrade account #134

[stanly-johnson]

So this pallet should be a DAO factory, with every DAO having an option for a token for activities?

[olanod]

Correct @stanly-johnson 😉 It can be that it eventually becomes a full-featured DAO management system but as usual we can start simple making use of what we have, it can be that we just end up putting different existing pallets together without having to do much on our own. We can start listing the different use-cases that we imagine our communities might need and welcome feedback from our users who might have specific pressing needs(@S0c5?)

[olanod]

Feature list to edit based on priority.
EDIT: tracking issues in the original post
- [ ] Membership. How to keep track of user involvement in a community. pallet_membership might work for a while as our communities are counted but we'll need a dynamic version of that pallet. Also we might not need to store every single person that joins the community but only the "admins"? Another idea that comes to mind is having an AccountData structure as the balances pallet to store the user's list of joined communities.
- [ ] Account. A key-less account controlled by members of the community. Basically the treasury pallet but for any number of treasuries.