User:Mike-ZeleaCom/Architecture

This design attempt is abandoned. It was tailored for rapid, distributed deployment, but we lack the resources for that. And I can't figure out how to hack workarounds without wrecking the design. The problems are:

Over-reliance on third-party wiki hosting services

The immediate problem is that vanilla MediaWiki can't do preference routing. The user can't click on a "vote" link and arrive at his preferred pollserver. This is crucial for free-range voting.

I added external preference routing, but it's a an ugly hack. (On second thought, it's probably a reasonable design. Routable URLs are not restricted to wiki content, but may appear in any medium. So external PR is probably ideal. But the general problem remains.)

The general problem is that hosted wikis are too inflexible. We can't reconfigure and extend them, so we're sure to encounter other hard limitations. If we plant the architecture in this environment, it'll grow up twisted.

Too many wikis scattered around

Users will balk at the proliferation of pollwikis. They'll become confused. This will stall the deployment.

To mitigate the problem, I placed the poll positions in the local streetwikis. But this requires a central registry for area names, positions namespaced by area, and preference routers that do area-routing, as well.

Administrators will be overwhelmed by the complexity of deploying incremental technical changes across a network of pollwikis and streetwikis. We don't have the infrastructure and practices for that, yet. It all takes time to build.

A prototype open architecture for e-democracy is described. The architecture is intended to be open in the sense that it provides its users with freedom of choice, not only in political decisions, but also in the tools that enable those decisions. The principal design requirements are user choice, and rapid deployment. These requirements are met by a distributed network of wikis (streetwikis, pollwikis and mapwiki) augmented by supporting servers (trustservers and pollservers). These components are coordinated as defined by the following interfaces:

Area mapping

Defining area names for issue posting and user identification.

Issue posting

Defining the specific issues that.

Position posting

Publication of candidate poll positions.

Preference posting

Publication of user preferences.

Registration

Setting registration properties.

Registration posting

Transparency of registration data.

Trust extension

Extending trust and navigating the trust network.

Vote posting

Transparency of vote data.

Voting

Defines methods for voting and viewing results, and preference routing among pollservers.

Overview

Registration is facilitated by streetwikis and trustservers. A single streetwiki is provided for each sub-sovereign region or municipality. The user registers her local streetwiki (A below), then cross-authenticates with her neighbours (B). The streetwiki and its associated trustserver comprise the local voter register, as shown at bottom.

Local. Voting on local issues.

Voting is facilitated by pollservers. Pollservers work in conjunction with the issue posting interface of the streetwiki. Anybody may define an issue via the issue posting interface (C above). The user may then vote on the new issue via the pollserver of her choice (D). The votes are mirrored across all pollservers, so they effectively share the same pool of votes.

State. Voting on state issues.

The aggregation of all local registers of the state comprises the state register (above bottom). State issues are defined in a dedicated state pollwiki (A above), and typically voted in a dedicated state pollserver. Poll positions are still defined locally (B), regardless of issue area (local, state, federal or global).

Federal. Voting on federal issues.

Federal issues are defined in a dedicated federal pollwiki, with its attendant pollservers. The only structural difference from voting on state issues is the aggregation of multiple state regsisters into a larger federal register (above bottom).

Global. Voting on global issues.

Multiple pollwikis are expected at the global level, beyond the scope of sovereign jurisdictions. Global area mapping is therefore factored out to a dedicated mapwiki (top right). This mapwiki defines the sub-registers (of federations and unfederated states) that comprise the global register (above bottom).

Requirements

These are the design requirements for the architecture as a whole. For the more detailed requirements of individual frameworks and components, see the related documents.

Rapid deployment

The design is to be rapidly prototyped and deployed to about 10,000 users. Ordinary requirements are to be relaxed for the sake of deployment speed. In particular, the prototype need not scale beyond 10,000 users.

User choice

User choice of tools and components is to be maximized. Top-level components and tools are either selected according to individual user preference, or they are forkable. In the latter case, they ought also to be locally distributed, and the users ought to participate in their development.

Personal selection

Ideally, the choice of component is made by the user according to personal preference. The user may select from an array of alternative components. The array is open ended. Anyone may develop a new component and offer it to the users. The new component is to have access to the same basic, common resources as the old components. Users may switch back and forth amongst components without loss of basic functionality.

Forking

If the component is not a personal selection, then it is to be forkable. Anyone may duplicate the component (fork it) in a crisis. The viability of the fork will not depend on any mass migration of users; rather, users may migrate individually or in small groups.

Local distribution

If the component is not a personal selection, then it ought to be deployed in a locally distributed fashion. Users may then customize the component according to local needs.

Participative development

If the component is not a personal selection, then it ought to be developed participatively, with the users responsible for the bulk of development and day-to-day maintenance.

Facilities

These are the common facilities of the system. The common facilities are functional features that cut across multiple components from different suppliers, such that different suppliers either cooperate in the provision of the facility, or share in its use.

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 to discover orignal votes, and the issue posting interface of the pollwiki to establish poll equivalence. Having discovered a newly cast vote on the source pollserver (A), 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 issue posting interface. The user may freely range across all of them.

Free-range voting also depends on preference routing. (Need a picture of that.)

Residential voter registration

(For a universally tight list)

Logical list posting.

Actual list posting.

Shows how the trustserver component intermediates for multiple streetwikis, each of which is sunk into its particular locale.

Single sign-on

(Via MediaWiki API.)

See also

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

• Opening an architecture - Precursor of the present document, proposing the basic idea of an open architecture.

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

The present design is based on the definition of large-scale frameworks and components. By contrast, EML, OPOL and xDebate take a more 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.

Terms

architecture

The top-level design of a system. A collection of frameworks and large-scale components.

component

A structural part of the system, such as a streetwiki or a pollserver.

facility

A functional feature of the system, such as free-range voting or residential voter registration.

framework

A set of written standards that says how various components work together in order to provide a facility, such as the registration framework.

free-range voting

The facility to wander from pollserver to pollserver without restriction and without loss of basic voting context.

pollserver

A component of a voting site. It maintains a voter list, implements a voting interface, and stores original votes.

streetwiki

A semantic wiki that serves as the front end of a local, residential voter register.

vote mirroring

The replication of votes between pollservers, such that an original vote cast on one pollserver (source) is shadowed by a mirror image on another (destination).