FreeCoop: A platform for democratic labour organization

Movement Ideas
#1

FreeCoop aims to be a tool for organizing democratic organizations, with a focus on commercial, labour organizations.

FreeCoop is built on three pillars:

  1. Decision Making
  2. Groups
  3. Accounting

Decision Making (Decision API)

Internet Voting (I-Voting) is a difficult software to implement.

FreeCoop relies on Decision API for implementing secret, certified and extensible I-Voting.

Decision API is another Social Coding project developed by me, so let me introduce it here in detail.

Decision API is not supposed to be invoked directly and instead decisions and accounts should be created by some service, such as FreeCoop.

Account Managment

An account contains a UUID id and a an optional name string.

When an account has been created, it’s id is returned to the creator (usually the services using Decision API).

This services then issues the id to the person, they want to use the account, who can then exchange the id for an authorization token.

After an authorization token has been issued for an account, it cannot be changed or reissued. And the authorization token remains valid for the lifetime of the account.

To access the account and account actions, the authorization token needs to be provided in a request for a temporary access token - of which there may be several for any one account.

An example service should only know the ID of accounts, they created, not their authorization or access tokens, which should be stored on the device or in an encrypted storage only accessible to the person designated to use the account.

When an account’s authorization token is lost, the account can no longer be accessed and there is no method for regaining access to it. In such a case, services should create a new account and designate them to the person, who lost their authorization token.

Extensible Voting Methods

The most controversial part of discussing digital democratic processes, is the question of what voting method is used.

Long discussions can be had about the benefits and disadvantages (or even dangers) of certain voting methods over others.

Because no definitive, general answer to these debates can be found, DecisionAPI does not implement any voting method itself.

Instead anyone can add a voting method to a Decision API in the form of Python code, implementing this function:


def count(proposals : frozenset, ballots : frozenset, participants : frozenset, proposer_franchise : frozenset, voter_franchise : frozenset ) -> bytes:

    return b"Result"

There are some restrictions on this code, though:

  • Imports are prohibited. The instance operator can define a set of libraries to be available to all voting methods, but voting methods cannot import their own libraries.
  • Builtins that executed I/O actions, such as open, print or input, are not available in the voting method’s code.

Besides these restrictions, designed to reduce the risks of executing arbitrary, possibly malicious code on the server, all voting methods have to be signed by a code auditor, trusted by the instance operator prior to being used by a decision and the server executing the code.

Decisions

When a decision is created, the service creating it must specify:

  • Who is allowed to vote and make proposals? The franchises.
  • When proposals can be made? The proposal phase.
  • When votes can be cast? The voting phase.
  • What voting method should be used (it has to be signed by a code auditor)?

The proposal phase must precede the voting phase.

After the voting phase has concluded, the decision has concluded and the Decision API instance executes the voting method’s count on the ballots, proposals, participants and franchises of the decision.

All proposals, ballots payloads and the result of the count method are bytes.

After concluding the decision and calculating it’s result, the instance signs the result and the parameters of count that lead to the result and publishes this signature and the result. This also includes the ballots cast in the decision, which have until now been kept secret on the instance of Decision API.

Due to the signature, a service can now download the decision result and can verify it independently from the instance of Decision API. This means that Decision API instances can delete old decision results and expect services using the Decision API to download decision results within a certain time out.

Authorities

Authorities are public keys stored on the instance and given some abilities by the instance operator.

Currently two abilities are supported:

  1. is_decision_authority is an authority that can be used to sign the results of a decision. An instance has to have at least one of these for which the private key must be stored on the server itself.
  2. is_code_auditor is an authority that can sign voting method’s code. An instance should have at least one code auditor, but depending on the size and number of voting methods awaiting review, an instance operator might ask multiple trusted people to become code auditors and share the work load.

Groups

FreeCoop itself is a service relying on the Decision API. People can interact with it directly to organize themselves into groups.

Every group has a chronological list of all decisions every taken by it.

Group members can be given roles and associated permissions within the group via a decision.

Within a group, a charter defines what types of decisions can be taken by the group and which roles are permitted to vote or make proposals for a specific decision type.

The groups that can be organized in FreeCoop should have as much freedom in their internal organization, as possible.

Accounting

FreeCoop explicitly wants to able to help commercial groups. Groups with an income and expenses.

Conclusion

It should be evident where the development of FreeCoop is currently at, by the amount of detail I am able to provide in this post. As the Decision API is the basis for the rest of FreeCoop, I have concentrated my attention on developing, testing and now documenting Decision API as a first step towards implementing FreeCoop.

I’ll post updates on the development of FreeCoop here as part of my efforts to remove myself from the ivory tower of software development and interact with anyone interested in the project.

1 Like