Votorola is software for hosting free and open elections. It formalizes a medium of assent in support of communicative action, mutual understanding and consensus. It provides communities with a supportive structure for political decision making, in the form of an independent electoral system. This page documents its overall design.

Votorola implements an electoral system. The system is structured as a physical network, overlain by multiple logical networks. The physical network is composed of sites. A site is a primary node in the physical network. There are two types of site: electoral offices, and synchronized sites.

Figure 1. An electoral system is built upon a physical network of 1 or more electoral offices, and zero or more synchronized sites.

Electoral offices are the core of the physical network. They are organized in a tree of super-offices and sub-offices that together provide electoral services to the public in multiple districts at a different levels. Synchronized sites (if any) are organized in a peripheral sub-network. It receives data from the core network of electoral offices, and uses it to conduct system monitoring and oversight; host external elections; and provide extended electoral services.

Overlaying the physical network are multiple logical networks or media. Topmost are a trust network for authenticating the voter lists, and a delegate cascade voting medium. On these are built the core services of the electoral register and the elections.

Electoral Offices

The physical network contains one or more electoral offices. Electoral offices are primarily administrative units. Set up and operating procedures are documented in the administrator's manual.

Multiple offices are organized in a tree of super-offices and sub-offices. The sub-offices at bottom correspond to the smallest, local districts (counties, municipalities, and so forth), while those above correspond to larger districts that combine the electorates of two or more sub-offices. The reason for multiple offices (as opposed to a single central office) is two-fold:

• to broadly distribute the costs of system deployment and operation
• to root the system in the local communities that it serves

Figure 2. Tree of electoral offices in a fully deployed system, with branches serving populations of different sizes. As each branch descends to smaller and smaller districts, it is roughly limited in depth by the overall population of the higher district.

Larger populations, such as those of large states, are served by branches having greater depth, that extend through intermediate, medium-sized districts (provinces, or sub-federal states). Figure 2 shows different populations and the branches that serve them. The only purpose of the super-offices in this arrangement is to support super-jurisdictional elections, such as heads of state and national laws. They are not intended to have any authority over the sub-offices (in fact, they will be loosely dependent on them for their electoral registers). Each electoral office is to be administered independently.

Figure 3. An electoral office, showing major node types, communication interfaces, and actors.

Each office deploys server nodes. For a minimal configuration, the major server types are mail, electoral, file and database, as shown in Figure 3. The deployment may combine multiple server types in a single physical hardware node; so the mail and the electoral servers, for example, may actually be a single computer.

The office also deploys communication interfaces, including:

• mail and Web-based voter interfaces, to maintain electoral data
• file-based watchdog interface to verify election results
• command line administrative interface
• database synchronization interface for cross-site communication

Electoral Subserver

# # # # # # # # # #
- an electoral subserver is a variable store of electoral data, 
  that is maintained by voters and administrators,
  and made accessible through communication interfaces (see figure 3 above)
- it is implemented in code class ElectoralSubserver (source, API)

- one or more electoral subservers per server
- each with an electoral subserver account
    - an electoral subserver account is a local user account on the electoral server, 
      that is dedicated to the storage of the subserver's data,
      the running of its daemons, and so forth
    - an electoral subserver name is the user name (login)
      of an electoral subserver account
    - each subserver account has a home directory in the file system,
      an account with the database management system, and so forth
        - all typically under the same name
- a typical installation has at least two subservers:
    - an on-line subserver, for public use
    - an off-line subserver, to pre-test new services and software
    

Figure 4. An electoral subserver showing where the electoral data is stored (file and database servers), and how voters access it via electoral service daemons (mail or Web) and various services. Administrators can access the same services via command-line executables, and the same data via local interfaces (not shown).

Electoral Services

# # # # # # # # # #
- an electoral service is a facility for voters 
  to access and maintain a specific class of electoral data on a subserver
- it is implemented in code class ElectoralService (source, API)

- by default, Votorola ships with three types of service:

    * electoral meta-service for overall information about services
    * electoral register to identify the voters
    * delegate cascade elections for them to vote in

- these may be extended, by third parties
    

Extended Electoral Services

# # # # # # # # # #
- other service types may be coded and added to a Votorola installation, as third party extensions
    - in particular, it is possible to add support for elections
      based on other voting mechanisms
    - the new election (etc.) could rely on the built-in electoral register,
      and the built-in voter interfaces
        - the developer need only write the service-specific code
- this would involve 
    a) writing the code for the service, and the specific service class
        - in the case of an election, the developer would code a service package,
          perhaps following the example of votorola.a.election
    b) jarring the package, and related library code, and adding it to the runtime classpath
    c) documenting the administration of the service
        - as in manual.xht#Elections
        - but instead of 'votorola.a.election.Election', for example,
          the service configuration script would point to the newly defined service class:

            function serviceType() { return 'service-class-name'; }
    

Electoral Meta-Service

# # # # # # # # # #
- an electoral meta-service is an electoral service concerning electoral services
- it provides
    - bootstrap instructions on accessing the electoral services
    - general information about the subserver, its purpose, the services it offers, and so on
    - facilities for creating voter-defined services (such as voter-defined elections)
- a subserver may provide multiple meta-services
    - typically there is one tailored for each electoral service daemon,
      and its specific voter protocol
    - Votorola ships with:
        a) MailMetaService for email (source, API)
        b) WP_Meta for the Web (source, API)
    

Electoral Service Daemon

# # # # # # # # # #
- an electoral service daemon is a process of the voter interface 
      that intermediates and translates between the voter protocol (e.g. email or Web)
      and the electoral service protocol (API)
    - [misnomer, it should be something like 'voter interface daemon']
- there are multiple daemons, providing multiple voter interfaces
    - Votorola ships with:
        a) vomailrd for email, with its backing MailResponder (source, API)
        b) VApplication for the Web (source, API)
    

Electoral Registers

An electoral register is an electoral service (code package votorola.a.register, source, API) that allows the public to maintain a database of information in order to:

• identify voters
• establish their eligibilty to vote in particular elections
• enforce a limit of one vote per person, per election

Each electoral office has a single electoral register to cover its electorate. Individual voters register with the local office, as shown in figure 5. Higher juridictional offices obtain their registration data indirectly from sub-offices. Consequently, the higher registers are exact aggregates of the lower.

Figure 5. A network of two district levels, showing information passing from voters to electoral registers. Information passes first to the local register, thence to the register of the higher district via the synchronization interface.

The register of each local office has its own email address. For residents of Brisbane, for example, the register might be identified as ‘register@v6brisbane.au’. All voters in the Local Government Area of Brisbane City Council would send their information to that address, using the voter interface.

# # # # # # # # # #
- a single voter registration suffices for elections at all district levels
- each registrant provides the following information:

    1. email address
        - identity (ignoring case) of registrant for voting and other electoral messages
        - implicit (inherent in the communication channel)
    2. name
        - of registrant
    3. residence
        - typically a primary residential address
            - but it depends on the scope of the election
              (e.g. in a register for school elections,
               this might actually record the registrant's 'home class')
        - a single string in local conventional form
            - readable both by humans, and by the address parsing scripts
              of the local elections
            - for example, if street number comes first, and postal code last,
              then that might be sufficient for the script to determine eligibility
    4. link
        - Web, to information about registrant
    5. note
        - explaining or commenting on the registration
    6. list of other trusted registrants
        - this list, combined with the lists kept by all other registrants,
          yields the trust network on which the authenticity of the register is based
    

Trust Network

# # # # # # # # # #
- basic purpose is to derive a list of trusted registrants from the registry,
  i.e. to authenticate the voter lists
    - from this, to derive the voter list for each election
- implemented in code package votorola.a.register.trust, source, API)

- following is somewhat out of date
[ edges
    - trust edges are the only type of edge
    - duplicate edges are not allowed
        / only one edge can extend from voter A to voter B
        - an exception is made for some types of admininstrative edges (e.g. per seeding below)
[ range
    - edges have limited geographical range (neighbourhood scale)
      so all activity is locally accountable
    - ranges measured by postal codes, where available
    - ranges of voters are overlapping, and fully interconnected
        - so the overall network can grow beyond range boundaries, to any scale
        - for example, at least one adjacent postal code must be within range;
          and all other postal codes must be reachable through a series of valid traversals
[ seeding
    - in order to seed the network, the electoral office can extend trust edges
      to any number of initial voters
    - and can extend multiple edges to a single voter, initially,
      to bring her into eligibitly
        / this is an exception to the rule of duplicate edges
    - the network thus grows from the initial seed network(s) started by the electoral office
[ tracing
    - trace starts at the electoral office
        - all voter trust is ultimately traceable back to the electoral office
    - it extends through reachable nodes only
        - the electoral office is the only exception to this rule
          (being always reachable, and always trusted)
    - a reachable node has a number of incoming trust edges, beyond a minimum threshold
    - trust cycles are effectively discounted
        - an exploiter cannot register a subnet of fake voters, and benefit from their trust edges
        - only the nodes that are already reached can confer trust
    - reachable nodes are trusted
    

Doubt Signalling

Doubt signalling is an adjunct to the trust network, serving to indicate suspicious voter registrations. A doubt signal formally extends from one voter (source) to another (destination). A single source may extend signals to any number of suspicious destinations, but may extend at most one to each. Doubt signalling is implemented (together with the trust network) in code package votorola.a.register.trust (source code, API).

The negative messages of doubt signalling are complementary to the positive messages of the trust network. However, doubt signals propagate in a separate network of their own. The two polarities of message are kept apart, and never cancel each other in combination. This separation prevents the instability that would likely arise, driven by contention among sources and destinations, in a tit-for-tat escalation of messages. Instead, the formal authenticity of the register depends only on the positive messages of the trust network. The negative doubt signals, meanwhile, serve only to indicate that particular destinations in the network (particular voter registrations) are suspicious, and that the trust sources and registrars ought to consider withdrawing their trust from them. Any actual withdrawal does not follow automatically, but is conditional on the understanding and agreement of the trust sources. This inter-mediation of the opposing networks (by slow, thinking people) will prevent destabilizing reactions. The relatively slow response time for withdrawal will nevertheless be faster than any subsequent re-extension of trust to the untrustworthy destinations. This asymettry between the withdrawal of trust (quick and easy), and the re-soliciting of its extension (slow and difficult) will tend to deter abuse of the register.

Being the target of doubt signals does not formally affect a voter's inclusion in the voter list, nor her eligibility to vote in elections. Doubt signals are not needed therefore in order to compile a voter list, especially outside of the local office. Consequently they are not considered as part of the core voter input, and are not synchronized up to the super-offices.

Delegate Cascade Elections

Delegate cascade elections are electoral services for formalizing assent and building consensus in communities. They combine a delegate cascade voting medium for the open nomination of candidates, with a recombinant text compositional medium for the open proposal of normative texts (laws, plans and policies). They are implementated in code package votorola.a.election (source, API).

Figure 6. A network of two district levels, showing information passing from voters to elections. A single office hosts each election (and typically hosts many elections). Information passes directly from the voter to the election.

Any number of elections may be hosted by an electoral office. Each particular election is hosted by the lowest office that contains the full register of the electorate. For example, a member of a national assembly would usually be elected through a local office at the bottom level, since most constituencies are local; but the head of state would be elected through a higher national office. (A higher office would also host any lower-district election for which the electorate happened, somehow, to straddle a boundary between lower offices.)

An election may also be hosted by any synchronized site that contains the full register of the electorate. For instance, citizens might set up a synchronized site of their own, and hold elections to recommend candidates for key positions in the bureaucracy.

Voters vote using the mail-based voter interface, or one of the extended interfaces. The same interfaces may be used to track the results. For these purposes, each election has a unique email address. For instance:

• Mayor <mayor@v2toronto.ca>
• Member of Parliament for Trinity Spadina <mp-trinity-spadina@v2toronto.ca>
• Municipal Tax Share <bill-2017-tax-share@v4ontario.ca>
• Prime Minister <prime-minister@v47.in> (open to a direct vote)
• Foreign Policy <foreign-policy@v67.ca>
• Ombudsman for World Trade <trade-ombudsman@elections.int>
• Constitution <bill-2016-constitution@elections.int>

Voter Eligibility

# # # # # # # # # #
- main criterion of voter eligibility is usually the voter's primary residential address
- each election has its own detailed criteria,
  which it applies when counting the votes
    - script
        / for ease of editing by admin
    - input from electoral register, and output boolean
    - script is published
        - and human readable, (or better outputs reasons for false result),
          to help voters debug the format of their registration addresses, in extremity
    - for example, see the demo server's /home/votodemo/votorola/eligibility.js
    

Voter-Defined Elections

# # # # # # # # # #
    - created by voters, through an electoral meta-service
    - primarily intended for text-based elections (policy, legislation, etc.)
    - will require restrictions on configuration (for simplicity, security)
        - pre-coded choice of voter eligibility scripts, covering pre-defined districts
        - lesser configuration items (title of election and so forth) are taken
          from the currently winning draft

    - voter also has the option of running her own electoral server,
      using the synchronization interface to read the common electoral register
    

Voter Interface

# # # # # # # # # #
- this needs to be rewritten to better describe interrelations among:

    [ command-response layer
        - infrastructure in support of all plain-text, command/response voter interfaces
        - currently part of the electoral services, this layer will be separated off, soon
            - to save memory and boot time, especially in the Web interface
            - see my votorola/a/a.task: command-response layer separation
    [ core mail-based interface
        - basic fallback interface
        - providing specialized functions, as well, in support of universal voter identifiers
          (email addresses), shared by all interfaces
    [ new Web-based interface, currently being developed

    - and to remove unecessary details of the mail interface, below, to the manual instead
    

A voter interface allows voters to intercommunicate with electoral services. The core interface provided by Votorola is mail-based (email). In addition to the core interface, there may be extended voter interfaces (such as Web). Extended voter interfaces are not documented here. This section documents only the mail-based, core interface.

The voter interface accepts messages for the purpose of maintaining the electoral registers, voting in elections, and other essential electoral functions. It authenticates messages in order to verify sender identity. The basic authentication method is a handshake across a challenge filter: the apparent sender must reply to a specific challenge (Did you send this message?) before the message is accepted. (Other authentication methods may be made available in future, as alternatives.)

# # # # # # # # # #
- two messaging layers: authentication and response
    

Authentication Layer

# # # # # # # # # #
- outer authentication layer, to authenticate address of sender
    - bypassed if message contains no command that requires authentication
        / some messages, such as read-only queries, do not require authentication
- different methods of authentication will eventually be available, according to voter choice
    / e.g. challenge filter, or signed email
    - but challenge filter is the only one implemented at present

- structure:
    1. mail/tmda-filter-wrapper
    2. Tagged Message Delivery Agent (TMDA)
    3. spam filter, to suppress challenge of obvious spam
- usage manual.xht#TMDA
- function
    - nominal senders are challenged in order to authenticate them as actual senders
    - once authenticated, messages pass to the response layer
- localization
    - challenge message (TMDA template) will be in language(s) of sender's internet domain
    - otherwise:
        / global office might be the only one that needs this
        - use the top-level domain (country code) of the sender's address
          to select an appropriate template (which may itself be multilingual)
        - see TMDA configuration variable TEMPLATE_DIR_MATCH_SENDER
            / this is the best TMDA can do, at present;
              (it cannot read standard MIME headers, as the response layer does, below)
    

Response Layer

# # # # # # # # # #
- inner response layer, to respond to (act on) messages
- usage manual.xht#message-responder

- structure and function
    - message responder daemon
      feeds commands to electoral services; gathers their responses;
      and transmits them back to sender
- in exceptional cases, the responder may act repeatedly on the same message
    a) if processing of a message is interrupted by a server failure,
       the message will be reprocessed on a subsequent run
        - it is therefore possible that users will see multiple replies to a single message
            / but most re-processed messages will generate only a single reply
    b) a user might re-send a message
    - in any case, no critical anomalies will occur from partial processing of messages,
      or from repeated response to some/all of the commands they contain
- localization
    - respond with language, date formats, etc. according to sender's MIME header
      Content-Language, per RFC 3282 
        - http://www.ietf.org/rfc/rfc3282.txt
        - some canned messages will not be localized:
            - error messages
                - expected to be rare
                - typically in English, or programmer's language
            - messages from voter eligibility scripts
                - difficult to localize, so this is postponed
                - will be in primary language(s) of the electoral office's internet domain
    - respond in UTF-8
        - 7-bit characters (ASCII) will pass cleanly
        - 8-bit will be over-encoded for email (in whatever standard it uses)
            / presumeably the user's client can decode it,
              if they are used to receiving non-ASCII messages 
    

Watchdog Interface

The watchdog interface enables the public to verify the reported results of any election. It is largely a procedural interface. Its procedures have yet to worked out in full detail, and documented.

Reported election results (counts and so forth) are always based on discrete snapshots of electoral data. Whenever results are reported, a copy of the results together with the snapshot of the data on which it is based are combined into a single archive, and published through a file server. One may independently download the archive, inspect its data, and verify the reported results.

# # # # # # # # # #
- snapshot includes all voter and administrative input that contributed to the results
    - voter input (votes, registration, etc.) are necessarily public
        - but ideas on how (or whether) to allow privacy, secret ballots, and so forth,
          and how to reconcile this with public trust in the system
          will find time for airing/debate 
- archive size will be massive, especially for higher districts
    - will require special-purpose transport protocols
/ archive format still under design...

- intermediate results, such as hourly or daily counts, are backed by short-term archives
- decisive results, marking government election days and so forth,
  are backed by longer-term archives

- verification entails testing both the accuracy of the input data, and of the generated results
- see manual.xht#results-verification
    

Administrative Interface

The administrative interface enables system administrators to maintain electoral services and data from a server's command-line shell. Manual pages for the various commands are located under manline/man/. See also the administrator's manual.

Synchronization Interface

The synchronization interface (which is not yet implemented) has two clients: electoral super-offices, and synchronized sites. Electoral super-offices use it to mirror and combine the electoral registers of their sub-offices.

Figure 11. Synchronization by cascade between levels of electoral offices (left); between electoral offices and synchronized sites (middle); and among synchronized sites (right).

# # # # # # # # # #
[ synchronized site
    - any site mirroring the public electoral state (election and register tables)
    - synchronized sites may run Votorola code,
      using Votorola's application programming interface;
      and/or their own code
    - examples:
        | electoral watchdogs, monitoring agencies
          that verify accuracy/consistency of data
        | hosters of external elections
            - anybody can host an election, not only an electoral office
        | providers of other external services
          such as extended voter interfaces, electoral views, analyses, and so on
            / the first to be implemented might be a Web voter interface
- protocol is Postgresql Slony-I
    / cf. Oracle streams, SQL Server database mirroring
    - whether Slony-I will actually scale to the highest super-offices is not yet known
    [ Slony-I (plain)
        - for secure subscriber nodes (e.g. among/within electoral offices)
            - limited to about 6, but can cascade
    [ Slony-I Log Shipping
        / not well documented yet by developers
        - for insecure subscriber nodes
            - maybe can also use it among/within electoral offices, instead of Slony-1
        - can also cascade [presume]
- fixed relational structure, at first
    - until limitations of interface are known,
      structure of public tables is kept static
    - data (aside from primary keys) is stored in a single XML column,
      allowing it to change internally
    

Notes and References

Glossary

maintainer Michael Allan