Opening an architecture

[Friedrich Lindenberg]

Hi all,

thanks for that very interesting proposal, it certainly contains a lot
of food for thought.

>  *  Did I miss any obvious frameworks?

I guess there's some peripheral stuff that would need to be
considered, including WoT/PKI systems and Wave Federation (which I
think should not be reduced to a discussion medium, it goes far beyond
that) and the related OpenSocial standards (including things like
OAuth, PortableContacts etc.)

> 1. Registration framework
> -------------------------
>
> A registration framework is for identifying users and authenticating
> them as voters.  The framework below is already partly designed and
> implemented, as a pre-alpha prototype.^[2]

In which way is Votorola's registration framework open at this point?
Do you already have an API or data exchange format for this? I'd be
very interested to learn more about the way in which Votorola
currently does this.
I'm experimenting with OpenID Attributes
(http://wiki.piratenpartei.de/Benutzer:Pudo/Liquid_Democracy_-_OpenID_Extensions)
at the moment. This seems to work nicely in theory, although the
current proposal lacks any concept of voting domains (such as
districts, counties, states etc.). My first intuition here was to go
low-tech, i.e. by using URIs (wiki pages) to identify domains, by not
expressing any relations between domains (county X is in state Y) and
by not aggregating centralized registers, using signatures and a
decentralized model instead.

> What the sketch above
> says, basically, is that no matter what voting engine is available to
> the voter, and no matter what drafting medium, discussion medium or
> differencing engine she chooses to use, the same, basic differencing
> functions will be available.  So the voters are free to choose the
> tools.

This one gives me a bit of a headache: while I understand the interest
in somehow synchronizing discussions, it seems to me that this is
usually a bad idea. Within the discussion media and drafting media
boxes exists a large array of possible systems, including
document-based systems, threaded discussions, linear discussions,
structured arguments, annotations etc. Mapping between those would
condemn the developers to using the lowest common denominator
metaphor, usually "email".

While differences among position drafts take a central role in the
Votorola concept, this is a result of the concept of communicative
assent. It does not necessarily apply to LiquidFeedback (where
"Suggestions" form the central means of discussing a draft) and
Adhocracy (where specific "Provisions" serve to structure the debate).

A less ambitious goal might be to create unique identitfiers to point
towards specific debates. But even that seems hard, since, for
example, LF and Adhc distinguish between a problem and its solution,
while (AFAIK) Votorola does not. I also fail to see a concrete use
case even for this.

> 3. Classification framework
> ---------------------------
>
> A classification framework is for categorizing polls and positions,
> and creating navigable views.  The diagram below is a paper-napkin
> sketch, with no real design behind it.  We can at least forsee that
> classification is likely to require data input from most of the core
> components, as well as the voters.

I'm not entirely sure what kind of classification you're talking
about: classification of political areas ("Foreign Policy",
"Housing"), political orientations ("Conservative", "Progressive"),
typical argumentations ("too expensive", "impractical") or the
branches of a proposal (Votorola-style: "Green Conservative
Proposal"). While I guess that you're referring to the first and last
kinds of classification, I'd be grateful if you could describe a
typical use case for such a shared classification scheme to help me
see its application.

I'm also somewhat critical towards the creation of controlled
vocabularies within social software and would much rather discuss an
addressing scheme for shared tags.

> 4. Autocasting framework
> ------------------------
>
> An autocasting framework is a convenience for voters who are unable to
> spend much time in direct participation, but nevertheless wish to
> vote.  The central component (autocaster) is a personalized voting
> agent.  You (as a voter) choose a particular autocaster from among the
> competing designs, and then set it to work.  It analyzes your past
> voting behaviour with the help of classification engines, and based on
> this it creates a working profile of your interests.  It then locates
> matching candidate positions in various polls and recommends them to
> you.  If you allow, it will go even further, taking your place at the
> polls by casting and recasting votes on your behalf.  (You might still
> override it, of course, in particular polls.)^[5]

I still like this idea (originally found in Rodriguez' "Smartocracy"
paper), assuming that the autovoting mechanism is sufficient
transparent and verbose in order to keep the actual voter in the loop.
The main difficulty here seems to be mapping across different voting
concepts; I have not yet found a simple way of addressing such
inconsistencies among different applications. What good is a shared
vote-casting API if the implications of a vote within each system are
so vastly different?

In general I feel that we should focus on generating lightweight
standards regarding infrastructure tasks such as voter authorization.
While I do see the value of mapping concepts, discussions or even
votes, I don't see sufficient stability in any of the involved
packages to support such standardization. After all, we don't really
know which debates voters want (and need) to have, how they will want
to lead them and what tools are best suited to support them.

Cheers,

 Friedrich