It has been almost six years since we published the first version of LiquidFeedback in the autumn of 2009. Since then, we've constantly been improving the software in regards to the user experience as well as considerations regarding the democratic process implemented by the software.
LiquidFeedback is not only an implementation of Liquid Democracy (the idea of transitive, revocable delegations by topic) but also features a unique proposition development system where huge groups of people may discuss and decide in a self-organized way. It has always been the goal to abstain from the need for a moderator or request commission, and LiquidFeedback has been successfully reaching that goal in real world scenarios with up to several thousand participants.
With this Issue 4, we want to go further: we will present an approach to make the LiquidFeedback proposition development and decision making process feasible for a potentially unlimited number of participants. The article “A Finite Discourse Space for an Infinite Number of Participants” is the missing piece of the puzzle to create a process that scales – in theory – for an infinitely high number of people.
But we will also present new application fields of the LiquidFeedback process. Björn Swierczek will present not only theoretical considerations but also an implementation to connect LiquidFeedback with revision control systems.
Considering the widespread use of revision control systems in many application fields, this paves the way for democratizing work processes even in areas where such a level of democratization has not been thinkable before (e.g. infrastructural knowledge bases such as the Wikipedia). His implementation, included in this issue, has already been successfully tested in the lab, and will soon find its way into the official LiquidFeedback release.
Last but not least, Issue 4 will also contain an addendum to the mathematical proof on preferential delegation that has been presented in the last issue. We were surprised that, in between, Google Inc. released information about an internal Liquid Democracy experiment [GooglePaper] utilizing a preferential delegation system [GoogleVideo]. As shown by our proof, certain requirements cannot be fulfilled at the same time. This also applies to those experiments, resulting in negative voting weight in case of the given approach.
We would like to note that the proof regarding negative voting weight might be generalized further. Property 2 in the original proof [PD] might be removed from the list of contradicting properties if each case considers all possible partial permutations of voters. Since such formalization and generalization wouldn't change anything in regards to the practical impact of our findings, we will not provide a formal proof in this matter. Such a proof, however, might be of theoretical interest.
Liquid Democracy has recently been getting more and more attention by researchers, politicians, and even companies. The experiment done by Google Inc. is one example for this development.
While we are generally happy about the popularity of Liquid Democracy, we are also concerned about the fact that some properties of electronic decision making are constantly ignored, as so in case of Google's experiments.
As the experiment had to fulfill the “Google+ privacy policies” of the company, votes that did not use delegated voting weight (referred to as “personal votes” in the Google paper) were hidden from the users (“private”). [GooglePaper, p.12, pp.4-5] It should be noted that even if those votes are “private”, they would still need to be counted by the system. Google Inc. was and is probably still able to snoop through the data. While we always emphasized the need for recorded public votes in the context of democratic decision making using electronic media, Google Inc. decided to allow voters to cast votes “privately” as long as they do not use any delegated voting weight.
They refer to this conception as the “Golden rule of Liquid Democracy”. [GooglePaper, p.4] But not all that glitters is gold: it can easily be shown that this allows neither for a verification of the processes by the voters nor for casting votes secretly (i.e. Google Inc. could still know what everybody voted on). Therefore, the participants of the system did not have any way to check the results of the system; they had to blindly trust the results. It is obvious that such an approach doesn't meet democratic standards at all and thus should neither be called “Golden rule” nor “Democracy”.
As this was the first experiment of Google Inc. with Liquid Democracy, there is still the chance to correct such aberrations before creating a product for the general market. But it will be a big challenge to provide a solution which can be legitimately trusted by the users. This would require a completely transparent system which is verifiable by the users: all ballots must be published by the system and any algorithm influencing the democratic process (including any used sorting algorithm) must be public as well. For us, this seems to be contradictory to the business goals of Google Inc. at least at the current time.
Nonetheless, we do not want to criticize Google for experimenting in that domain, but we must warn people of using the term “democracy” for systems that cannot meet democratic standards. We do not want to live in a future where people are encouraged to vote “anonymously” while – in fact – a global corporation counts and records all votes. Cryptographic protocols are unable to provide a solution to this problem. [PLF, chapter 3]
If votes are being recorded, they must be recorded publicly such that all participants may verify the process, and all participants must be aware that they are not taking part in a secret ballot but in an open ballot. For all other democratic decisions (i.e. those democratic decisions that ought to be secret), we strongly suggest the use of physical ballot boxes instead of electronic systems.
We predict that the greatest challenge for a further democratization of platforms like the Wikipedia will be a proper accreditation of the participants (the only way to properly ensure one vote per real person) along with creating an acceptance for publishing ballots. Without publishing each participant's ballot in an electronic voting system, verifiability for the participants cannot be achieved. (For further details, refer to chapter 3 in our book “The Principles of LiquidFeedback” [PLF].) In no case can non-verifiable systems be called “democratic”, because systems which are not verifiable by the participants are never democratic.
We hope that the dream of a more self-organized and more democratic world soon becomes true, and that secret elections remain truly secret where they are needed.