A streetwiki is a semantic wiki that serves as the front end of a local voter registry, backed by a neighbourhood trust network. This page outlines the use cases and requirements for residential voter registration at the local level, and floats some design proposals. This is a work in progress; all are welcome to contribute.
- 1 Use cases
- 2 Requirements
- 3 Design
- 4 Glossary
- 5 Notes and references
[ARCH] Architectural context. Shows streetwikis and voter registration (bottom) in the context of a broader open architecture. (original)
Use cases are functional scenarios from the perspective of the user. Note that some of the scenarios assume a particular technical design, but for purposes of description only.
Compiling a residential register
The main purpose of the voter registry is to compile a residential register. The register includes the following properties, per registrant (user):
- Personal identifiers - online identifiers (email address, OpenID, and so forth) that identify the user on one or more vote-servers
- Location - specifies the electoral districts, and so forth, where the user is primarily resident
- Trust level - provides a degree of assurance that the registration is bona fide
Most of the other use cases follow directly or indirectly from this main purpose.
Policing for local sock puppets
Note that users will have access to (a) all of the information shown on the following diagrams, such as street maps, locations of registrants on the map, and lines of trust; (b) the full residential address of each registrant down to the street and apartment number; which details will also be viewable on the map overview, perhaps as in this mockup; (c) each registrant's email address and other online identifiers; and (d) all other data from the register.
[SOCK1] Creation of isolated sock puppet network.
A user (C) registers several fake users (sock puppets), and extends trust to them [SOCK1]. C then tricks another user (D) into trusting one of the sock puppets. With two trusters, both at a level of 2, the entire network of sock puppets can rise to 2 by cross-authenticating [SOCK2].
[SOCK2] Soliciting external trust.
A third user (A) eventually notices that the locations of the sock puppets are bogus. She informs C and D. D withdraws trust from the sock puppets, but C does not. Consequently, A and B withdraw trust from C [SOCK3].
[SOCK3] Detection and withdrawal of trust.
C cannot easily regain trust by re-registering under another identity. Her address on Riverside Park is known. Any re-registration at that address is going to be suspect.
C (above) asks friends to extend trust from a remote neighbourhood. They try, but range limitations (2 km or so, in the city) prevent them from extending trust. The remote neighbourhood is not burdened with responsibility for policing actions that do not concern it.
Policing for remote sock puppets
A user lives in one place, but has a second residence elsewhere. The two places are served by different local voter registries. The user registers at both. Later, an acquaintance is browsing through the other registry and notices the second registration. She explains to the user that he ought to register only at his primary residence. He unregisters from the other place.
Verification of registers
A technically inclined user wishes to verify the registrations of the voter register for her hometown. She visits the trustserver (see diagram), and finds the output directory in which the registers are stored. It is the same directory as used by the vote-servers, to compile their voter lists:
She copies the current snapshot to her own computer. Here it is, at time of writing:
Based on the snapshot of user input (
_in_registration.txt), she compiles a register using the same software as the trustserver used. She then compares the output to the trustserver's original register for her hometown (e.g.
Tor.xml). The two match exactly.
Next she verifies the user input itself. From the revision history of the streetwiki, she recreates the state of the user pages at the time just prior to the snapshot. She then issues the same command that was issued on the trustserver in order to generate her own snapshot of the user input (
nice votrace snap --churn
She compares the two files. They match, except for a single registrant/user. She looks at the revision history for the corresponding user page and sees that the page was edited by the user at about that time. This explains the discrepency.
She checks with a wiki verification service. It reports no incidences of revision-history tampering, for that streetwiki. She concludes that the register contains no errors, and the registry can probably be trusted. (She re-checks it now and again, just to be sure.)
A neigbourhood defines itself. It is not an administrative unit. Users lay out their own neighbourhood and way-segement pages. They add their own links to local resources, and so forth. They use the associated talk pages to discuss local matters.
Some users are unfamiliar or otherwise unskilled with computers. They may include the elderly, the physically/mentally infirm, and children.
The requirements generally follow from the use cases. Each requirement specifies the use cases that it enables.
Handshake verification of trust extension
When a trust edge is extended from a source user (S) to a destination user (T), it may typically extend only to T.username (wiki identifier). In that case, S must confirm that T.identifier (typically email address) is the intended target. For example, S must receive a confirmation message that clearly specifies T.identifier (not T.username) as the recipient of trust.
In addition, the person identified by T.identifier must confirm (or have already confirmed) that T.username is her own. For example, she must receive a message that identifies her as T.username. It should therefore be difficult for an imposter T to solicit trust, either by using an incorrect T.identifier (her own); or the correct one, with the intention of altering it later.
Required for integrity of trust extensions in #Compiling a residential register.
Public user location
Trust levels alone are insufficient to detect sock puppets. The residential address of those trusted must also be made public.
Required for #Localized responsibility.
Data are recorded in snapshots
User input and registers are stored as snapshots, and made available for purposes of verification. Snapshots are static. No alteration is ever made to the data within a snapshot.
Required for #Verification of registers.
Correct way orientation
Ways that run east/west on the ground are presented horizontally in the wiki. Although vertical alignments may be easier to implement in some cases, they are too disorienting.
Required for #Unskilled users.
Way segment pages
Ways may be broken into relatively short segments (way segments), displayed on separate pages. Local users may customize the title, layout and content of way-segment pages. Content may be added above/below any template-generated views.
Required for #Local self-determination.
Ad hoc neighbourhoods
Neighbourhoods and way segments may overlap and cut across each other.
Required for #Local self-determination.
The design is currently being prototyped as a part of a larger open architecture. We have a testbed implementation of a streetwiki (with no street layouts yet) and a running trustserver. The design is still fluid.
Dist 1. Local distribution of registries.
Dist 2. Detail of registry structure. Shows how the trustserver component intermediates for multiple streetwikis, each of which is sunk into its particular locale.
The trust network is a directed graph of user-to-user trust edges that are extended by the users for the purpose of cross-authenticating the voter registry. Individual trust edges are stored as wiki properties in the source (user) page. During compilation of the register (by the trustserver), the edges are traced to determine the level of trust for each particular registration. These levels are then incorporated into the resulting register.
A trust edge extends from a source to destination user node (T). It pertains to the following attributes of the latter's registration:
- T.identifier (email address is likely to be best, for this purpose)
The trust edge asserts, “Yes. That's the email address of my neighbour across the street, she's a real person, and she really does live there.” More formally:
- T.identifier is the identifier of a person (P) living at T.location. It is not the identifier of a bot or other imposter, posing as P.
- T.location is the primary residence of P.
- P is registered exactly once at T.location. For each other user (U), where U.location equals T.location, U.identifier is the identifier of a person other than P.
A given source node may extend trust to any number of destination nodes (subject to any bars imposed by the configuration), but may extend at most one edge to each. The extension of trust is configured and controlled by runtime scripts on the trustserver.
In a fully elaborated network, each destination node is evaluated at a particular level of trust, which is recorded in its entry in the register. The recorded level (t) depends exclusively on the levels among the source nodes, where it is calculated as the highest level that does not exceed the count n(t) of sources at that level or higher. In other words, to have a trust level of 3, a voter must have 3 or more immediate trust sources, each itself having a trust level of 3 or higher.
- t ≤ n(t)
- (t) is the trust level
- n(t) is the count of immediate source nodes at level (t) or higher
The ultimate trust source is the root node, which is the trustserver administrator. All trust edges must be traceable to the root, otherwise they are discounted in the elaborated network. Unlike an ordinary node, the root has a high (effectively infinite) trust level, and it may extend any number of edges (primary trust edges) to the same destination.1 The maximum trust level in the network is limited by the redundancy of primary edges extending from the root.
translating from here
but talk pages (users, buildings, streets) are maybe sufficient for expressing doubt
A proxy blind is a proposed method for implmenenting a private voting option. It works by splitting the registrant's identity in two: 1) a registration ID and 2) a voting ID or proxy. The equivalence of the two ID's is a secret between the registrant and registrar (the blind). The identity of the voter, as such, is therefore unknown to anyone else.
No design sketch has been attempted yet. See the design discussions under Talk:Streetwiki#Proxy_blind, from which these notes are excerpted:
* User registers under R-email, which gets trust from neighbours. Neighbours say that R-email is not a sock puppet. * User votes under V-email, which is vouched by registrar. * Only registrar knows that R and V-email belong to same person. * User promises never to vote using R-email. Registrar checks now and again to confirm that R-email never votes.
So you can never vote with R-email or do anything else that ties it to V-email. You have two registrations in streetwiki: R-reg: R-email + street address (real) V-reg: V-email + street address (surrogate) + personal identifiers (OpenID and so forth) for other voting engines
We have to be clear about the problems - basically that we cannot *really* assure them of privacy yet. Otherwise, if we give the wrong intial impression, it will be difficult to defend the technology from attacks in the mass media.
a) Streetwiki with trust network, to i) Verify residential address, and ii) Verify honesty of (b) and (c); b) Additional registries to authenticate residential address by other schemes, including by authority; and c) Proxy blind to keep registration and voter ID's separate, if that's what a user wants.
Streetwiki user interface
An early proposal for the layout of a way (street etc) is http://zelea.com/project/streetwiki/way.xht. It doesn't yet meet the requirements.
See also the more complete definitions of the registration framework.
- primary trust edge
- An edge that extends directly from the trustserver administrator.
- (n) A list of registrations.
- (v) To enter a registration in a register.
- One who is registered. The subject and object of a registration.
- registrant identifier
- A registration property that uniquely identifies the registrant. Every registration has at least one registrant identifier. Registrations with multiple identifiers assert equivalence of those identifiers. There is no canonical identifier type, all types are equally valid.
- The responsible official who maintains a source register and certifies its integrity.
- A registrant identifier and associated registration properties, as entered in a register.
- The overall process of maintaining registries and registering.
- A component for maintaining a source register.
- sock puppet
- A second registration under a false identity. See http://en.wikipedia.org/wiki/Sockpuppet_(Internet).
- source register
- An authoritative register maintained by a registrar.
- trust network
- A directed graph of user-to-user trust edges that are extended by the users for the purpose of cross-authenticating the voter registry.
- use case
- A functional scenario from the perspective of the user. A way of using a system.
- A road, corridor, canal or other passage along which residences are situated.
- way segment
- A relatively short, lengthwise portion of a way.
Notes and references
Credits should also be added here. Meantime, please see Talk:Streetwiki.