[pp.int.general] Liquid Democracy - a summary attempt

[carlo von lynX]

On Mon, Apr 28, 2014 at 09:44:01AM -0300, seykron wrote:
> Nice summary!

Yes, Zbigniew. Thanks for a constructive contribution to this list.

> Some comments on that:
> 
> > 1. The Liquid Democracy concept
> > In democracy everyone should have equal power - but when the limiting
> > factor is time - then those who have more time to play the political
> > games have more power - and you get the 'vocal minority' problem. But
> > I am not sure if LD really fixes it or maybe it just replaces it with
> > another problem (a patronage system?).

People don't like representative democracy (when other people decide)
but they like even less when they are invited to participate and yet
the representative side of liquid democracy plays a stronger role than
the direct one. This makes it hard to understand that they are actually
participating in a better democratic system, because if there was any
reason to doubt the representatives, the direct democratic approach
would take over. So logically thinking it is better, but it feels worse
superficially. What to do about it? Delegate less?

When LQFB was first launched we were very thrilled by it, and we liked
this concept of having each person participate directly or indirectly.
Not making use of delegation was seen as throwing away your privilege
to vote. Missing out on having your voice be counted, even if you weren't
that much in control of it after all - it happens quite frequently that
the delegate, as much as you may like and trust him, has a different
opinion on certain topics than you. So we probably exceedingly made use
of that delegation mechanism, which led LQFB to feel quite representative
and little direct democratic at times. The new trend of having pretty
harsh minimum_ttl configurations is probably a healthy counterbalance -
it makes people use liquid democracy more consciously.

> Regarding LD, I think it address some problems like "lack of time", but
> it still has the same issues of regular representative delegation.

If you have too few participants and you don't wrap any usage regulations
around it, you can end up having both negative extremes of direct and 
representative democracy at times. Like no-one finding the time to
counter populist proposals.. and quora that are so low, that the problem
even appears. Using LQFB takes collective social wisdom, but that is the
case with any form of democracy. If you didn't have the wisdom to write
reasonable regulations that determine how the thing works, then all
sorts of things can go wrong. It's just a software. The group using it
must define how to employ it reasonably.

> > 2. The Liquid Feedback software implementation
> > The LF dev team is completely incompetent in leading a Free or Open
> > Source Software project.

Uhm, well they are a bit complicated to work with, but they are nice
folks really. And they did an impressive job to make this thing in a
few months in 2009-2010. But the Austrians are maintaining a nice fork
of it. Try it out.

These questions would be answered quite differently for Agora voting,
so I am only saying what I know about LQFB:

> 1. Is it a centralized database?, despite whether votes are encripted
> or not, how do you avoid hacking (and I mean adding more votes, for
> instance) from someone with physical access to the database?

No encryption. Downloadable database. There should be external tools to
let you recompute the correctness of the results. If the attacker changes
a vote after results have been published, he would have to correct the
results. That could get noticed by anyone who has noted down the results
or has a backup copy of the database. If the attacker changes a vote
during the voting phase itself, then he takes the risk that the person
he voted for will notice or will be informed, especially since your own
vote is shown to you as you check the results. A very advanced attacker
would modify LQFB in such a way that it shows you different results from
other people - in that case comparing a downloaded database would either
show the incorrectness of what was shown to you, or the databases that
two seperate people download would not be identical.

All in all it is a good idea to have very trustworthy people in the role
of running your LQFB instance, but there is a whole toolset of methods
to enable you to automate consistency checks. I just don't know if this
is being done anywhere.

> 2. How do you avoid MITM attacks? (ok, maybe SSL is good enough, but it
> is still an issue)

Since hardly any pirate uses Certificate Patrol to check the correctness
of the certificate, MITM is quite a likely scenario. It would allow an
attacker to obtain a password, then later do things in the name of the
observed person. The person would hopefully notice that at some point,
especially if she is a superdelegate and everyone runs up to her asking
why the hell she voted that way.

Procedures for dealing with such a case obviously cannot be provided by
the software, they would need to be specified in the regulations.

> 3. How do you avoid XSS attacks? If someone stole my login cookie, how
> do I get to know he or she is voting on my behalf (or removing my
> votes)?

For XSS attacks you need to have suitable bugs. The rest is the same as
with MITM.

> 4. *Who* defined the calculation algorithm? Is it just a simple
> majority or is there any other mechanism created ad-hoc? If it is
> simple majority, how do I know that the system is not just adding +1 to
> choose a specific decision?

The Schulze method is described even in Wikipedia. There are independent
implementations of it that you can run your database data against.
LQFB allows for any kind of percentage majority - they need to be defined
by regulation. There can be as many voting policies with differing
durations, quora and majority formulas as the group likes to configure.

> 5. Who leads the development team? who manages the infrastructure?, who
> have write permissions on the main repository? how do I submit bug
> fixes and how many time I have to wait to have my patch applied?

The administrators of an instance usually do not do any software
development, accept patches or bug fixes. That's to be done by developers.
When the developers release a new version publicly, an operational
decision (the board possibly) is made to execute the software upgrade.
Or maybe not. It is good, that these roles are seperate.

> 6. Who provides the money (and it is very important) to support this
> development? Why investors are putting money on that?

Maybe some deployments actually pay contributions to the development.
There may also be money flowing from the EU's D-CENT project.
I'm not familiar with that - I have always only invested time and
money into this.

> Maybe it is quite enough for the moment, and probably much of these
> questions have a "rational answer", but it is hard to me get convinced
> of the safety of these systems.

That's why the time isn't right for leading a country with them, yet.

> > 3. The social practices around usage of Liquid Feedback
> > I am sure that even once we have a good LF software - it will take
> > long time to work out the right social practice around it. Voting in
> > general is a very confrontational way of making decisions, but it is
> > the only one that scales.
> 
> I agree with Cal. on this. It is true that direct democracy practices
> did not work on the past (or it did work in small groups), but here I'm
> not thinking on a consensus at society level. We are immersed in a
> representative system, so we have to deal with it. But we have the
> ability to build a progressive bottom-up power as well, and technology
> also helps (as LF) to address problems from the past. It is not
> "better" than representative democracy, it is another choice, with
> another problems.

We tried a consensus-fostering software platform for a bit, it's called
"Vilfredo goes to Athens." It adapts a model from a liberal Italian
economist to direct democracy. Each time a participant does not like a
certain proposal the software asks him to rewrite the proposal in such
a way that he would like it. That means a whole lot of work, and when
all participants have finally settled on something they all find
acceptable it probably watered down to some populistic phrase or motto.

I think the Pirate movement actually found an interesting balance
between confrontation and consensus by using etherpads upfront. You
first brainstorm all the stuff and try to work towards something
everyone likes, and then if you really can't agree on some aspects
you throw them at LQFB. Still I recommend to not take any decision
with less then 2/3.

> And regarding problems, as software developer I did learn that it is
> impossible to solve a problem you still do not have. It leads to a
> complex and over-architectured system which finally do not scale.
> Abstract thinking is useless if it is not directed to a specific issue,
> and it is a big trick for software engineers: abstract thinking "seems
> to be real" because it is a logic structure, but usually it is very far
> from the real problem and tends to fulfill programmers egos instead of
> solving use cases. Sometimes we fall in the same trap thinking about
> society and organization strategies.

Interesting. I frequently sense that dissatisfaction with the outcomes
of LQFB votings trigger a hunt for problems that do not actually exist
while negating the ones that lead to the dissatisfaction.