User:Mike-ZeleaCom/Opening an architecture

This page scrapes together some rough framework sketches, and floats them as a kind of architectural “kite”. It is intended to promote discussion. The diagrams are technical, but most of the text is aimed at the general reader. The exception is the rapid prototyping proposal, which is aimed at software developers.

An architecture for e-democracy is “open” in as far as it provides its users with freedom of choice, not only in political decisions, but also in the tools that enable those decisions. Openness hinges on a number of technical and legal conditions (see glossary), but perhaps the most important criterion is technical inclusiveness. The frameworks of the architecture must be open to the widest possible range of tool designs, from all suppliers. This aspect of openness is explicated in the framework sketches below.

Registration framework

A registration framework is for identifying users and authenticating them as voters. The framework below is not yet designed, apart from some tentative draft requirements.

What the sketch above says is that different locales (C City, R Region, and so forth) can maintain their own voter registers. They can also choose their own software for this purpose from any supplier. Each supplier's register component is plug compatible with those of other suppliers, so they all work together in a coordinated fashion. Coordination is necessary so that voters can register at the local level, and be authenticated just once, yet vote in all polls (municipal, federal, and so forth)..

Not only the voter registers are plug compatible, but also the pollservers. So C City might be using a Liquid Feedback pollserver, while R Region is using an Adhocracy pollserver and D City is using both (not shown). Voters in D City would therefore have a choice of which pollserver to use.

Voting framework

A voting framework is for casting votes and viewing results across the pollservers of multiple, competing suppliers. No voting framework has yet been designed, but the following use cases have been proposed.

Free-range voting

In free-range voting, users may wander from pollserver to pollserver without restriction and without loss of basic voting context. Their votes are effectively pooled across all pollservers. Free-range voting depends on the technique of vote mirroring. Vote mirroring is the replication of votes between pollservers, such that an original vote cast on one (A) is shadowed by a mirror image on another (B). Vote mirroring may be implemented using an autocaster in pull mode, as shown below.

Vote mirroring.

In this example, the autocaster is deployed as a component alongside the destination pollserver. It depends on the vote posting interface of the source pollserver (A) to discover original votes, and the poll identification interface of the pollwiki (right) to establish poll equivalence. Having discovered a newly cast vote on the source pollserver, the autocaster translates from source poll to destination poll, and creates the image within that context on the destination pollserver (B). The user might now switch from A to B. Because both pollservers share a common voter register (left), her identity as a voter is unaffected by such a move. She would find her votes mirrored as expected on B, and could pick up where she left off.

The diagram above shows only part of the picture. Site A also has an autocaster of its own (not shown). It too is pull-mirroring votes, in this case from B. Mirroring therefore works in both directions and both pollservers end up with the same votes. Likewise for all the other pollservers whose polls are equated by the common poll identification interface. The user may freely range across all of them, and make an informed choice of which to use on a more permanent basis.

Personal vote filtering

Personal vote filtering enables the user to "dial up" customized results by selectively filtering a pool of votes. Effectively, the user compiles her own voter list and conducts a recount. This use case is poorly described, at the moment. For more information, see User:ThomasvonderElbe_GmxDe/Vote mirroring#Personal_vote_filtering.

Personal autocasting

Personal autocasting is a convenience for voters who are unable to spend much time in direct participation, but nevertheless wish to vote. The central component (autocaster) is a personalized voting agent. You (as the voter) choose a particular autocaster from among the competing designs, and then set it to work. It analyzes your past voting behaviour with the help of classification engines. Based on this, it creates a working profile of your interests. It then locates matching candidate positions in various polls and recommends them to you. If you allow, it will go even further, taking your place at the polls by casting and recasting votes on your behalf. (You might still override it, of course, in particular polls.)

The diagram at right is only a paper-napkin sketch. No personal autocaster has actually been designed. Whether or not it would be a good idea is still an open question. But if the voters wanted it, there is probably no way for the architects to disallow it. Anyone can add a new component or framework to an open architecture.

Difference bridge

A difference bridge is a text comparison server for deliberative democracy. It puts backbone into online deliberations by grounding them in concrete differences of position. It works in conjunction with peer-to-peer voting and drafting media, wherein the positions of voter and candidate are already formalized as text documents. In this setup, disagreements and misunderstandings are easily visualized as differences of text. The difference bridge goes a step further in allowing any particular difference to be referenced by a Web link, suitable for embedding in an online discussion. Participants may follow the link in order to summon a precise, stable view of the difference. Thus deliberations are formally anchored, at points, to the objects under discussion. Additional features of the difference bridge allow for locating other discussions of the same object across multiple forums; tracking the number of co-voters who share the same particular difference; and resolving differences by text merger.

The difference bridge and framework are currently under design. What the sketch above says, basically, is that no matter what pollserver is available to the voters, and no matter what difference bridges, discussion media and drafting media they choose to use, the same, basic difference services will be available. So the voters are free to choose their own tools.

Classification framework

A classification framework is for categorizing polls and positions, and creating navigable views. The diagram below is a paper-napkin sketch, with no real design behind it. We can at least forsee that classification is likely to require data input from most of the core components, as well as the voters.

Based on data from all these sources, a typical classification engine would provide one or more specialized voter services. One possible service is a navigable view. The navigable view shown below, for example, maps the current structure of a poll by labeling it with political interests. A new voter could use this view to locate a suitable point of entry in the pollspace — the position that is closest to her own interests — where she could place an initial vote, proceed to participate in discussion, and so forth.

Rapid prototyping

Rapid prototyping might be used to hack together an open architecture, prior to a full design effort. This is a description of the prototyping method. In summary:

1. Users set up a federation of semantic register-wikis (streetwikis);
2. Separate servers (trustservers) compile the registration lists and post them to the Web as flat files;
3. pollservers read the registration lists and compile their voter lists;
4. Vote data of each pollserver are likewise posted as flat files;
5. Other pollservers read the vote data and image the votes;
6. Users set up a federation of semantic poll-classifier wikis; and
7. pollservers query the poll-classifier wikis and cross-mirror the equivalent polls.

These hacks should suffice to implement the use cases of "register once, vote_anywhere" and "free-range voting" in as little as 6 weeks. Details follow:

   6      (C)  (C)  (C)       poll-classifier wikis
            \   |   /
        |    \  |  /
        v     \ | /
               \|/
3,4,5,7       ((P))           pollservers (many)
               / \
        ^     /   \
        |    /     \
            /       \
   2      (T)       (T)       trustservers
        ^  |\       /|\
        |  | \     / | \
        v  |  \   /  |  \
           |   \ /   |   \
   1      (S)  (S)  (S)  (S)  streetwikis

Progress

We have implementations of the trustserver (2) and the mirroring parts (4,5). As of January 7, we have a trustserver (2) serving a testwiki (not quite a #1, yet) where users are entering registration and trust information into their user pages (such as this user page). The calculated trust levels then end up in other wiki pages (such as this street page). More information is available here, along with the current data: http://reluk.ca/system/host/t/home/v/votorola/out/votrace/.

As of December 28, the mirroring parts (4,5) were implemented on Votorola's side. We're pulling votes from three different NationBuilder pollservers. For example, I can cast a vote on the NB pollserver in Australia. It is automatically imaged by Votorola's pollserver in Toronto. Imported votes are posted here, prior to imaging: http://reluk.ca/system/host/t/var/cache/votorola/v/in/vomir/. Votorola's own local votes are exported from here: http://reluk.ca/system/host/t/var/cache/votorola/v/out/vocount/.

We still need to set up a proper streetwiki (1); get the first pollserver to actually use the common registration data (3); and set up classification and cross-mirroring for all polls (6,7).

Method

1. Users set up a federation of semantic register-wikis (streetwikis). Steps (1 and 2) are a temporary hack for a chainable set of mutually tight residential registers.
   1. Users set up a semantic streetwiki for each city or region that wishes to participate. They may use a free host like referata.com. The registers must be geographically disjoint (non-overlapping) in jurisdiction.

      Each street is given a separate page in the wiki, and each block a separate page section. Intersections are linked to cross-street pages, so users may easily "turn corners" as they navigate through the neighbourhood. Blocks contain buildings, and buildings contain residents. Each resident is linked to a user page.

   2. On each user page, the user enters registration properties. A template is provided for this. The registration properties include:
      1. Primary residential address
      2. Personal identifiers (Email address, OpenID, and pollserver-specific usernames) for each type of pollserver that is participating in the prototype
   3. On each user page, the user may extend trust edges to other users. She may also extend doubt signals. Templates are provided for these.
2. Separate servers (trustservers) compile the registration lists and post them to the Web as flat files. Each trustserver is associated with one or more streetwikis (1). For each server/wiki pair:
   1. Obtain the registration and trust data from the streetwiki (1), via a semantic query.
   2. Trace out the trust network and compute the trust level of each user. Compile a registration list including the user properties (above), plus the authorative property of:
      3. Trust level
   3. Post the registration list to the Web.
   4. Write the trust levels back to the streetwiki as multiple semantic properties of a single protected page. Local queries may reference the trust levels and show them to users, but users may not alter them.
   5. Recompile the registration list periodically, as needed.
3. pollservers read the registration lists and compile their voter lists. This is a temporary hack for the list compiler.
   1. Copy the registration lists from the trustservers (2).
   2. Chain the registration lists together and translate them to the pollserver's native voter-eligiblity format. The result is effectively a voter list for that pollserver. Its content will be equivalent to that of the other pollservers' lists.
   3. Recompile the voter list periodically, as needed.
4. Vote data of each pollserver (source pollserver) are likewise posted as flat files. This is a temporary hack for the "vote monitoring" interface. For each votable issue:
   1. Create a new poll (aka. "issue").
   2. Export all of the poll's original votes to a text file (vote list). For each original vote in the list, record the particulars that define it. The exact format will depend on the pollserver's voting method, but just as an example:
      1. Subject identifier (voter)
      2. Object identifier (delegate or proposal)
      3. Timestamp
   3. Post the vote list to the Web.
   4. Re-post the vote list periodically, as needed.
5. Other pollservers (destination pollservers) read the vote data and image the votes. This is a temporary hack for a pull-mode autocaster. For each source pollserver to pull from (4):
   1. Copy the vote list from the source pollserver.
   2. Translate each original vote to an image vote in the destination pollserver's native format.
   3. Re-pull the vote list periodically, as needed.
6. Users set up a federation of semantic poll-classifier wikis. These are a temporary hack for classification engines. In each wiki:
   1. Users create a separate page for each issue that is being addressed within the wiki's jurisdiction.
   2. For each issue, users identify the polls that address that issue. Thus poll equivalence is established across all pollservers.
7. Pollservers query the poll-classifier wikis and cross-mirror the equivalent polls. For each pollserver/wiki pair:
   1. Cross-correlate the polls of the local pollserver with those of remote pollservers, via a semantic query issued to the classifier wiki (6).
   2. Configure the autocaster for each local poll (5), such that the votes of the equivalent remote polls are mirrored.
   3. Re-correlate and re-configure periodically, as needed.

The shared voter registrations (1,2,3) will enable users to wander from pollserver to pollserver, without restriction. The vote mirroring (4,5,6,7) will effectively pool their votes across all pollservers. Thus free-range voting may be implemented as an extended-alpha prototype. Users may then vote up system policies, rules, plans and designs — and elect system administrators, registrars and other officials — even while the system is being developed and deployed.

See also

• The “killer app” of public participation   General requirements for an open e-democracy application.

• Architecture - Aborted design attempt.

• Project plans for Votorola - Rough outline of current protyping efforts.

Related documents

• Registration framework - Common standards for identifying users and authenticating them as voters.

• Streetwiki   The design of the residential voter register, in particular streetwikis, neighbourhood trust networks and trustservers.

• Vote mirroring - The enabling technology for free-range voting.

Other approaches

Our approach in the present document is based on the definition of large-scale frameworks and components. By contrast, EML, OPOL and xDebate take a bottom-up and data-centric approach.

• Election Markup Language (EML)   XML schemata for traditional elections.

• Ontopolis schema (OPOL)   OWL/RDF schemata for interest groupings and positions.

• xDebate - Semantic HTML (POSH) schemata for federated debate on political issues.

Glossary

architecture

The top-level design of a system. A collection of frameworks.

component

A large-scale part of the system, such as a pollserver (Adhocracy, Liquid Feedback, Votorola, etc.) or drafting medium (MediaWiki, MixedInk, etc.) or discussion medium (mailing list, Web forum, etc.).

framework

A set of written standards that says how various components work together in order to provide a coordinated function. So there is a framework for the function of voter registration, coordinating local authentication and global voting; another framework for position differencing, linking discussions of the same differences across multiple forums; and so forth.

open architecture

An architecture that provides its users with the widest possible range of tool choices. A collection of frameworks that is 1) public; 2) free of intellectual property exclusions; 3) extensible; and 4) compatible with the widest range of actual component designs, from all suppliers.

use case

A functional scenario from the perspective of the user. A way of using a system.