Deployment of the Outcast voting network


Not yet properly documented. Some rough points:

The pollwiki is the most important structural component in the network. It serves as a deployment container for several classes of function:

  1. Shared database among separate facilities of the network. These include competing facilities such as vote-servers from different suppliers, so it's crucial that the wiki be neutral in this function. Its database is best limited to those data that are needed to support the most essential services such as poll identification, that are required by all competing vote-servers. The wiki may be lightly loaded with other services that are somewhat less common or essential, but it might often be better to factor those out to other facilites.
  2. A default UI layer of views and controls onto the shared database (1). Since we deploy the database in the form of a semantic wiki, we automatically get a UI layer that lets users interact with it.
  3. A default drafting medium for poll positions.

Note that function (1) is for the most part unique to the pollwiki and irreplaceable. The pollwiki is the only facility for this. Functions (2) and (3), on the other hand, are not unique. The pollwiki only provides a default UI onto its database and a default drafting medium. Other UIs may be layered atop the wiki or attached via the network, and other drafting media may be added via supports for free-range drafting. These structural freedoms are intended to absorb any forking tensions that might otherwise split the voterbase.

Note also that function (2) is poorly performed by the pollwiki. The wiki's integrated UI is of poor quality for any purpose aside from collaborative drafting (3). It may suffice as a default or temporary stop-gap for (2), but hopefully it will not be long before the users have better alternatives to choose from.

For a more information, including a running example of a pollwiki, see

Deployment areas

A deployment area is an administrative scope within which a set of voting facilities are independently installed, maintained and operated. The deployment area may correspond to a city, state or organization, or it may be defined in some other way by its administrator. There are no restrictions on the definition of deployment areas.

Every deployment area is associated with a single pollwiki. The administrator may choose to deploy a dedicated pollwiki, one that serves that area alone. In this case, the polls of the area are identified by separate pages in the wiki. The area itself (dotted lines in figure below) need not be formalized in the dedicated pollwiki, nor in any other facility of the core network. It is purely an administrative concept without technical representation.

UML diagram
Deployment areas and associated pollwikis. Shows four areas that are associated with dedicated pollwikis (top and right), and two that are formalized as separate area pages in a common, multi-area pollwiki (bottom left).

Alternatively, the administator may create an area page within a multi-area pollwiki. In this case, the area is formalized as a top-level page of the wiki while its polls are formalized as subpages. The area name thus forms a part of each poll name and is therefore subject to the poll naming restrictions. Examples of area and poll pages within a multi-area pollwiki are Tor and Tor/p/grfin.

Graduated rollout from a multi-area pollwiki

UML diagram
Rollout stage 1. The administrator defines and maintains a new area within a multi-area pollwiki.

In stage 1 of the rollout, the administrator defines a new area within a multi-area pollwiki. The area's voters are automatically served by the pollwiki's associated cluster of servers. Ordinarilly all areas of the pollwiki (*) are served by a single instance of each server type (1), such as a particular project or vendor's model of vote server (model A is shown above). The area administrator has no privledged access either to the servers or to the pollwiki itself.

UML diagram
Rollout stage 2. The administrator deploys an independent cluster of the most essential servers.

In stage 2, the administrator deploys an independent cluster of the most essential servers. Each server is configured to serve only the administrator's area in the multi-area pollwiki. The vote servers of the new cluster are configured for unidirectional mirroring of the votes originally cast within the old cluster (mirroring left to right, not shown).

UML diagram
Rollout stage 3. The administrator deploys a dedicated pollwiki for the area.

In stage 3, the administrator deploys a dedicated pollwiki for the area. The area is then more-or-less independent of the previous voting facilities. It may continue to mirror the old votes for some time (not shown). The original area page and subpages need not be removed from the multi-area pollwiki. They may continue to be maintained by other administrators, and may spawn further independent areas in future.