Streetwiki
From Metagovernment - Government of, by, and for all the people
A streetwiki is a semantic wiki that serves as the front end of a local voter register, 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.
Contents |
Here would be diagrams that place the streetwikis and local register
within the broader context of an open architecture.
For now we have only this:
(C) (C) (C) poll-classifier wikis
\ | /
| \ | /
v \ | /
\|/
((P)) pollservers (many)
/ \
^ / \
| / \
/ \
(T) (T) trustservers
^ /|\ |\
| / | \ | \
v / | \ | \
/ | \ | \
(S) (S) (S) (S) (S) streetwikis
Use cases
Use cases are functional scenarios from the perspective of the user. Note that some of the scenarios assume a particular technical design. But this is for purposes of description only.
Compiling a residential registration list
The main purpose of the voter register is to compile a residential registration list. The registration list 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 pollservers
- 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
Sock 1. Creation of isolated sock puppet network.
A user (C) registers several fake users (sock puppets), and extends trust to them (sock 1). 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 (sock 2).
Sock 2. 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 (sock 3).
Sock 3. 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.
Localized responsibility
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 voter registers. The user registers at both. Later, an acquaintance is browsing through the other register 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 registration lists
A technically inclined user wishes to verify the registrations of her local voter register. She visits the trustserver (see diagram), and finds the output directory in which the registration lists are stored. It is the same directory used by the pollservers, to compile their voter lists:
She copies the current snapshot. Here is what it looks like (imagine this is on her own computer):
She uses the same software used by the trustserver in order to compile a registration list, based on the snapshot of user input (_in_registration.txt). She then compares the output to the trustserver's registration list. It matches exactly.
Next she verifies the user input. 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 semantic query that was issued by the trustserver, and generates her own snapshot of the user input. It all matches, except for one user. She looks at the revision history for the corresponding user page. The user made a change at about that time, which 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 registration list contains no errors, and the register can probably be trusted. (She re-checks it now and again, just to be sure.)
Local self-determination
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.
Unskilled users
Some users are unfamiliar or otherwise unskilled with computers. They may include the elderly, the physically/mentally infirm, and children.
Requirements
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 registration list.
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 #Policing for local sock puppets and #Policing for remote sock puppets.
Range-limited trust
Required for #Localized responsibility.
Data are recorded in snapshots
User input and registration lists 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 registration lists.
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.
Design
The design is currently being prototyped as a part of a larger open architecture. We have at testbed for trying out implementation details at http://okidoke.referata.com/. There is no working implementation yet. The design is still fluid. (In any case, implementers need not follow any particular design, and local administrators/users may choose their own.).
Dist 1. Local distribution of registers.
Dist 2. Detail of register structure. Shows how the trustserver component intermediates for multiple streetwikis, each of which is sunk into its particular locale.
Trust network
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 register. Individual trust edges are stored as wiki properties in the source (user) page. During compilation of the registration list (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 registration list.
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)
- T.location
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 registration list. 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)
- where:
- (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 registrar. 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. (Probably these privledges will apply to all registrars, we need to clarify the terminology.) The maximum trust level in the network is limited by the redundancy of primary edges extending from the root.
Compiling a residential registration list
Doubt signaling
translating from here
but talk pages (users, buildings, streets) are maybe sufficient for expressing doubt
Proxy blind
port here from private emails between Thomas and Michael, ~2010-01-02, 01-21
option of having separate identities for registration and voting, w/ correlation known only to registrar (or to machine), so effectively voter is anonymous
many limitations, experimental only, use at own risk, but we can probably prototype it
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.
Glossary
- primary trust edge
- An edge that extends directly from a registrar.
- registration
- A personal identifier and associated registration properties, as entered in a registration list. See the registration framework.
- The overall process of maintaining registers and registering.
- registration list
- A list of registrations.
- sock puppet
- A second registration under a false identity. See http://en.wikipedia.org/wiki/Sockpuppet_(Internet).
- 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 register.
- use case
- A functional scenario from the perspective of the user. A way of using a system.
- way
- 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
Hopefully we'll have the MediaWiki cite extension, for this section. Credits go here too.
