User:Mike-ZeleaCom/G/p/frvp:Prototyping the whole of e-democracy

From Wiki
Jump to: navigation, search

In prototyping the whole of e-democracy we aim to develop all essential facilities and core competences, in order to produce a first functional toolset. Although other toolsets have been developed in the past, none of them was ever functional for purposes of e-democracy, because none of them met the overall requirements. Mark Murphy was perhaps the first to address the overall requirements in his “killer app” essay,1 and the present plan attempts to address them practice. The plan is as follows, with completed items blocked out:



Online voting is the "e" in e-democracy. Pollservers are required in order to formalize consensus, which is the only legitimate basis for a democracy.

Deploy the essential voting facilities in one or more pollservers. Here's what's missing in Votorola:


Allow multiple areas (cities, states) per pollserver (PS).

Move area and district configuration out to the pollwiki (PW), where the users can take charge of it.

 |      PW  pollwiki (common)
 |      PS  pollserver (only Votorola, at present)

Unlimited polls, configured in pollwiki

Move poll configuration out to the wiki.

Allow for ad hoc construction, where the poll is created by the first vote.

Residential registry

Registries are for authenticating votes. Authentication is required because unauthenticated votes are worse than no votes at all; they cast doubt on the practice of democracy as a whole. A residential registry implements just one type of authentication that may co-exist alongside others. For a first implementation, however, a residential registry has advantages.2

Prototype the residential registry, including streetwiki (SW) and trustserver (TS). Integrate these with the central polling facilities.

   |      PW SW  integral pollwiki/streetwiki
   |      PS TS  pollserver/trustserver

Compile a voter list

Have the TS compile a separate registration list per SW area (city, local region), and post it openly.

Have each PS aggregate the registration lists (residential from TS, member rolls from various organizations) into a single voter list that combines all properties (residential, organizational) that are required for its particular polls.

Enforce eligibility based on divisions

Add local divisions as explicit registration properties in SW user pages. For example, the user specifies all local electoral districts in which she is resident.

Add other divisions as implicit registration properties. The pollserver deduces these when compiling its voter list, based on the location of the registrant's SW.

Enforce eligibility based on trust

Have TS trace the trust network across all areas, and set trust levels as registration properties. Ranges of trust extension (person to person) are unlimited at first (across continents and oceans). Later, as the network condenses and strengthens, the ranges will be tightened (ultimately down to neighbourhood scales).

Set minimal trust levels in PW divisions, and apply these during PS counts.

Enable users to police the registry

Interlink user pages on lines of trust, so users can trace trust to its sources. (Who trusts this registrant? Who trusts the trusters?)

Prototype the layout of the streetwiki ways, neighbourhoods and so forth, so users can navigate trust in a residential context. (Who is trusted on my street? Do any sock puppets claim to reside in my neighbourhood?)

Free-range voting

Voters must not be fenced in by competing facilities. They are neither cattle nor consumers. If their inherent potential for consensus (and dissensus) is arbitrarily constrained or split by non-political competition, then it will never be realized. Without the potential of consensus, democracy itself fails.

Wait for the first non-Votorola pollserver (voting site or tool) to hook into the common architecture. Share votes with it. Let the users try it out and wander freely between the servers.

     / | \
    /  |  \
   /   |   \        PW  pollwiki (common issues)
  /    |    \       PS  pollserver (Votorola and others)
(PS)--(R)---(PS)    R   preference router
  \    |    /       TS  trustserver (common registrants)
   \   |   /
    \  |  /
     \ | /

Interface with discussion media

Communities of practice are not portable. The tools of e-democracy must reach out to people wherever they are already engaged with each other, which means via their existing lines of communication.

Code a bare-bones difference bridge. Explore and develop the interface with discussion media.

Data archiving and verification facilities

Verification is required, because unverified results are worse than no results at all. They cast doubt on the practice of democracy as a whole.

Record all vote shifts in the database, not just the lastest vote dispositions. Re-implement the snapshot export interface, moving it from the filebase to the database.3

Allow for independent verification of poll results, based on static snapshots of vote, configuration and other input data.

Distributed architecture

Democracy is a decentered thing. It exists in the peripheries, because that's where the people are. If the facilities are not likewise distributed, then they are not facilities of democracy.

Wait for the first area to request separation from the central site. Help it go independent with its own wiki and servers.

(PW SW)    (PW)    (PW)
   |        |       |
   |        |       |
   |        |       |
(PS TS)    (PS)    (PS)

           area    area

If it's a local area with a streetwiki, then subscribe to its registration lists from the central pollserver. The local registrants may then vote everywhere.

See also

Designs in support of this plan

  • Architecture - (aborted) Recent design attempt for e-democracy as a whole. Without architectural document such as this, the present plan lacks an overall design. But since it is only a prototype, and since many of its individual components do have formal designs (see below), it's probably OK.
  • Difference bridge - Text comparison facility for deliberative democracy. It puts backbone into online deliberations by grounding them in concrete differences of position.
  • Streetwiki   The design of a residential voter registry, i.e a registry in which the authentication criterion is residence. The main components are streetwikis, neighbourhood trust networks and trustservers.

Notes and references

  1. ^ a b Mark Murphy. 2008. The “killer app” of public participation. In Rebooting America. Edited by Allison Fine, Micah L. Sifrey, Andrew Rasiej and Joshua Levy. Personal Democracy Press.

    See also his later comments in the mailing list of the Metagovernment Startup Committee, February 2009.

  2. ^ The advantages of authentication based on residence include universal tightness, so there are no cracks for sock puppets to slip through. Also, voters and politicians are familiar with this form of authentication, so there is no need to explain why the votes should be taken seriously. For more on the rationale of residential authtentication, see:
  3. ^ Historical records of vote shifts must be implemented early on. Aside from allowing more efficiency in the generation of public snapshots for verification purposes, the history will serve another crucial purpose. It will provide a strong safeguard against vote buying. See the last item (v) at