User:ThomasvonderElbe GmxDe/Vote mirroring

Vote mirroring is the translation of a vote between two sites or forms, where the original on the first is replicated as an equivalent image on the second. All the different vote-servers could connect through such a mirroring facility. Through autocasting all the votes from one server could be mirrored in all the other servers. So the user of each server sees where else the same issue is being discussed/voted and with what results. This could solve two difficult problems:

• Split consensus - Mirroring can unify a consensus that is artificially split among vote-servers. With mirroring, voters can reach consensus on a particular political issue, even when they are unable to agree on which server to use. The problem is solved because a user of one server appears as a voter on all servers.
• Irrational competition - Mirroring can rationalize the competition among vote-server providers. With mirroring, the providers can only compete for users on the basis of whatever features and services they provide. They cannot compete for voters as such, and thus divide the votes. All vote-servers share the same voters and votes.

Definition of terms

component

A structural part of the system, such as a voter register or a vote-server.

destination vote-server

The vote-server of an image vote, on which the vote is maintained by the autocaster.

image vote

The active replica of a source vote.

original vote

A mutable vote that is maintained by the user of a particular vote-server.

poll scope

The scope of mirroring that encompasses an entire poll. See #Comparability of results in poll scope.

poll result

The tallied votes of a poll, as reported to the users.

scope of mirroring

Either vote scope or poll scope.

source vote-server

The vote-server of an original vote, on which the vote is maintained by the user.

vote mirroring

The translation of a vote between two vote-servers, where the original on the first (source) is replicated as an equivalent image on the second (destination).

vote scope

The scope of mirroring that encompasses an individual image vote. See #Validity of image in vote scope.

vote-server

A component that stores and maintains a voter list and original votes.

Use cases

So assume we have vote mirroring. What is it good for?

Free-range voting

A user switches from vote-server A to vote-server B. She finds it easy to port her user registration over to B, because the two vote-servers follow standard user identification practises (OpenID, email address, and so forth). More important than user identity, her identity as a voter is unaffected by the move. She finds her own votes placed as expected on B, and is able to pick up from where she left off.

Later, she changes her mind. She goes back to vote-server A. Everything is exactly as she left it there, except for any vote shifts she made while using B. Those vote shifts are faithfully replicated on A. She therefore pays no price for her brief experimentation with another vote-server.

Coexistence and rationalized competition

All vote-servers co-exist and develop side by side. The Pirate Party of Germany chooses a vote-server from supplier A. Vote-server A therefore gains 80,000 users (or whatever the membership is). But we all celebrate, because we all gain 80,000 voters for our own vote-servers.

Co-existence means competing only for users, not for voters. So it may happen that some users want to switch over to vote-server B. Those users won't pay a political price for switching. Their votes will still count. Cf. #Free-range voting.

New vote-server in town

We're guessing both push and pull modes will be used in practise, but it'll mostly be pull. Thinking of it from the admin's perspective: he installs a new vote-server from supplier B. He also installs an autocaster in pull mode. In pull mode, it copies the votes from all the competing vote-servers in town (or wherever). It might take a few weeks to mirror all the votes (it must follow robot etiquette and go slowly, so not to overload the other vote-servers). But maybe even before there's a single user for the new vote-server, it has all the votes, and they're kept in sync. So there's no disadvantage for the new vote-server in town.

Cross-server delegation

Further possibilities that come to mind are things like: delegates of one vote-server (and not just abstract delegates) voting in another vote-server. They would be like bridges between two vote-servers, representing the communication of the users of two vote-servers. This of course depends very much on the specifics of the voting procedures. But some vote-servers look compatible to Votorola in at least one direction.

Free expression

The administrator of a vote-server (P) attempts to restrict access to a select group of users by blocking the votes of others, up front. An alterative vote-server (Q) is set up. It mirrors the votes of P, but allows all users to vote. Users who were formerly blocked on P are now free to vote on Q.

Other users may still filter the results as they see fit, after the fact. Q therefore allows both free expression and filtered results, thereby making P redundant.

Personal vote filtering

Personal vote filtering enables the user to "dial up" customized results, by selectively filtering the pool of votes. Effectively, the user compiles her own voter list, and conducts a recount of the votes. The actual implementation requires a pull-mode autocaster to maintain a local pool of image votes. It also requires a list compiler and a count engine (both sub-components of a vote-server). These components are deployed on the client side (user desktop) in the form of a voting meta-tool.

Autocast modes

There are two autocast modes for vote mirroring: pull and push. Pull works for the administrator. It copies votes from all vote-servers to the administrator's own vote-server, for all voters. Push mode works for voter. It copies votes from the voter's own vote-server to another vote-server, just for that voter.

Pull

Pull mode requires no setup by the voter. The voter need not be aware of the destination vote-servers that are mirroring her votes. Presumeably this will be the default mode for a typical vote-server, if the user has not explicitly disabled it.

Vote-server A exposes a "vote posting" interface to which any number of clients may subscribe (maybe over XMPP transport). The sole subscriber in this case is the autocaster, and it uses the interface to image the votes on its local vote-server (B). So B gets all the same voters as A. (Interestingly, B has no users yet.)

A poll identification service is also needed (right). It maps poll identity between the two vote-servers. Thus the autocaster knows where to shunt the image votes - this vote goes to the property tax poll, this to the foreign policy directive, and so on.

Also, the vote-servers share registers in common (left). These are required in order to determine voter eligibility.

Push

Push mode gives the voter absolute control over the mirroring process on a particular destination vote-server, if desired. The voter must sign up for a user account on the destination vote-server, and pull mirroring must be disabled there.

Vote translation

Here are some concrete examples of vote translations for autocast mirroring. The exact algorithms would depend on the particular autocaster in use. The idea here is to find weird results or pathologies that cannot be corrected for. Mirroring won't necessarily work between all vote-servers, especially in both directions. And we don't ever want to force a translation to the point where it distorts the results.

Adhocracy to Votorola

An Adhocracy vote-server (A) is deployed locally, and someone raises a motion related to a municipal bylaw. It has three voters, one of whom is a delegate (H):

  vote-server: A (Adhocracy)
  poll:       A-motion/EN4J8, http://test.adhocracy.cc/motion/EN4J8
  method:     single transitive

       (F)
        |
        |
        |
   (G) (H)
    |  /
    | /
    |/
   (T)

  turnout: 3
  result:  T=3

A Votorola vote-server (B) is also deployed locally. It already has a running poll related to the same section of the municipal code. It's been running for a while longer, so it has a few more voters:

  vote-server: B (Votorola)
  poll:       B-P/grfin, http://reluk.ca/w/P/grfin
  method:     single transitive

   (J)         (P)
    |           |
    |           |
    |           |
   (K) (L)     (Q) (R)
    |  /        |  /
    | /         | /
    |/          |/
   (U)         (V)

  turnout: 6
  result:  K=1, U=3, Q=1, V=3

The poll identification service maps the motion to the poll A-motion/EN4J8 = B-P/grfin. B's autocaster pull-mirrors the votes from A. So now B looks like this:

  vote-server: B
  poll:       B-P/grfin, http://reluk.ca/w/P/grfin
  method:     single transitive

       (F)     (J)         (P)
        |       |           |
        |       |           |
        |       |           |
   (G) (H)     (K) (L)     (Q) (R)
    |  /        |  /        |  /
    | /         | /         | /
    |/          |/          |/
   (T)         (U)         (V)

  turnout: 9
  result:  T=3, H=1, K=1, U=3, Q=1, V=3

What's weird or pathological here? Mapping an Adhocracy "motion" to an entire Votorola "poll" allows only a single end-position (tree T) to the A voters. That's a little weird, because the B voters might have any number of alternative end-positions (U,V,..) to choose from. To mirror more than one motion per poll, we'd need to give Ahocracy the concept of exclusive (alternative) motions (or give Votorola the concept of fractional votes). But even without that, there's nothing pathological here.

Can anyone set up a more problematic example?

IRV to single transitive

Here is a mayoral poll on a rating method vote-server (C), with two primary candidates (T,S). There is no transitive delegation on this vote-server:

  vote-server: C (any simple rating vote-server)
  poll:       C-Mayor-Toronto
  method:     IRV

   (G)-->(S,T)

   (H)-->(T,S)

  turnout: 2
  result:  S=1, T=1

Here is a poll for the same issue (mayor's office), on the Votorola vote-server:

  vote-server: B (Votorola)
  poll:       B-P/m, http://reluk.ca/w/P/m
  method:     single transitive

   (J)
    |
    |
    |
   (K) (L)
    |  /
    | /
    |/
   (U)

  turnout: 3
  result:  K=1, U=3

Poll identities are mapped C-Mayor-Toronto = B-P/m. The autocaster pull-mirrors the votes from C to B. The ballot translation ignores all but the top-ranked candidate:

               (J)
                |
                |
                |
   (G)   (H)   (K) (L)
    |     |     |  /
    |     |     | /
    |     |     |/
   (S)   (T)   (U)

  turnout: 5
  result:  S=1, T=1, K=1, U=3

This seems benign. Can anyone set up a pathological case?

Requirements

These are the requirements (incomplete list) that a minimal design must meet.

Validity of image in vote scope

For an image vote:

1. The voter must have been authenticated as a user of the source vote-server, at the time the original vote was cast. User authentication entails verifying the personal identifier of the voter.
2. The vote translation (method to method) must be correct.
3. The polls must have equivalent prospective issues on both vote-servers.

Note that the validity of the image does not depend on voter authentication (proof of residence, organizational membership, and so forth), but only on user authentication (verification of the vote's personal identifier).

Comparability of results in poll scope

To claim that poll results on two separate vote-servers are comparably equivalent:

1. The two voter lists must be identical.
2. Every image vote that is eligible for the tally must be valid on both vote-servers.
3. The similarity of results between the vote-servers must not be less after mirroring than it was before.

Implementation

Votorola has implemented a rough prototype as a demonstration of vote mirroring. See VOMir.