Opening an architecture

[Michael Allan]

I apologize for the delay.  Everyone is so generous and thoughtful in
their replies.  I'm very excited by the possibility that we could find
common ground. :-)  Andreas Nitsche replies kindly in the Pirate Party
lists.  We have at least 3 solid projects, all with running code.

Everyone seems to be saying, this is just an ordinary technical
discussion.  There's probably no need to frame it in other ways.  And
also that registration is the easiest entry point.  Stepping back
then, one thing to talk about is maybe requirements.  So I took a stab
at a requirements doc.  (I realized along the way that my earlier
ideas for registration can't really stand up.)  I don't expect much of
this to survive, either.  This is just for discussion:

  http://t.zelea.com/wiki/User:Mike-ZeleaCom/Registration_framework

>From the context of Friedrich's OpenID method,
http://wiki.piratenpartei.de/Benutzer:Pudo/Liquid_Democracy_-_OpenID_Extensions

  ... the party state offices and state secretaries
  (Generalsekretäre) will serve as OpenID providers (OPs), the voting
  systems will be consumers, i.e. relying parties (RPs).

That would translate as:

  ... the party state offices and state secretaries
  (Generalsekretäre) will serve as *registrars*, the voting
  systems will be *clients*.

Replying to David, Friedrich and Martin.  David Hilvert wrote:
> Should vote tallying and collecting in general be considered a separate
> framework (or are you including it within Classification)?

Those would be separate, I guess.  For example, the verification of
tallies might require an API between two voting engines: 1) the online
operational engine, and 2) an independent verification engine.  But I
guess that framework would be proprietary (or it wouldn't much matter,
either way) because both engines would be from the same supplier.

Casting (vote collection) might be a little framework of its own, with
the engine exposing a "vote" method for generic clients.  That would
do away with my idea of a specialized "autocasting framework".  The
autocaster is now just a generic client within the casting framework.
(And this is maybe best.)

Friedrich Lindenberg wrote:
> 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.)

Wave seems to do everything - some kind of universal, media glue.  I'm
wondering if it could distribute and sync all the registration data
for us?  (I still have to read the docs.)

> 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 think I was wrong here, it turns out that none of Votorola's design
is likely to be relevant to the registration framework, per se.
Currently we have only a local voter register.  The only client is the
attached voting engine.  The two are glued together.  So it's not open
at all, yet.  The super-registers and syncronization interfaces would
have to be designed and coded.  (But now I see, that's probably not
the way to go.)

> 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.

I like your OpenID proposal.  It's an elegant way to solve the
immediate problem.  If I understand, it might not meet the most
general requirements (assuming we came to agree on some of those)
because it restricts authentication of membership to a single
organization, the one that assigns the login ID.  So it fails the
requirement of "Registers are non-exclusive".

My own proposal has the same fault, because it assumes the local
register as the sole authority.  And the local register doesn't know
anything about membership in the Pirate party, or in other parties and
organizations.

> 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".

(The requirements aren't so heavy, though.  One req is that the
 discussion medium must allow for embedded Web links.  So you can
 refer to particular diffs from within your messages.  The other is
 that the messages must themselves be Web addressable.  Most online,
 text-based media can do these things.

 But you're right, differencing is more for voting engines that work
 with P2P drafting, like Votorola and MixedInk.  And MixedInk isn't
 currently an open project, so differencing is probably off-topic
 here.)

> 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.

This framework is kind of hollow, I admit.  We'd have to put some
design guts into it.

One use case that might cut across all the projects is the
classification of "polls" (Adhocracy's "proposals", LF's "issues").
So the voters get access to an array of different classification
engines, that list/categorize/map the polls in various ways.  If we
designed the framework properly, then a single classification engine
might work across the polls of all voting engines, from all projects.

> 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.

I agree with you and Martin, folksonomies are the way to go.  In that
case, voting engines only have to expose poll identifiers.  Meanwhile
classification engine can scrape all the various media, extracting
tags of a pre-agreed format.  Users do all the primitive
classification work from within the familiar media environments.  But
the raw product of this work is exposed in a transparent manner, so
all the classification engines can harvest it.  Is something like that
workable?

Anyway, if we *could* design a framework like that, it might reduce
the risk for a developer who's thinking of joining us, and coding the
first classification engine.  There's no need for him to bet the farm
on a particular voting engine, and so forth.  He codes for the whole
field.

> 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?

(True, it's not so promising.  The autocasters themselves are likely
 to be engine-specific.)

> 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.

I guess that's true, it's all about exploration.  I'd only add that
the standards could be a good way to underwrite all that.  They can
act as a kind of safety net, and buy us time.  But I also agree, it's
only practical if we start with the easy pieces.

-- 
Michael Allan

Toronto, 647-436-4521
Skype michael_c_allan
http://zelea.com/