Metapolitics

[Conan Duke]

*Michael,*

Thanks for your interest and response.

First, in answer to your questions* (a, b & c)*

A voter registration database would be an important consideration. It seemed
logical to me that there would already be some sort of Open Source VRDB
(Voter Registration Database) Software being used in various projects.
Google begs to differ however - informing me that VRDB is the acronym most
commonly used for *''Variable Rated Demand Bonds" *(a financial instrument)
and to Avast Software's (a popular antivirus suite) *"Virus Repository
Database"*. Only Wikipedia had ever heard of such a thing where it is
referred-to simply as a *'Voter Database' *- a page containing some
surprising (and revealing) information on the subject:

*"The United States has no state or federal election agency, and thus no
central lists. In 2002, the United States Congress passed HAVA, the Help
America Vote Act. HAVA required that each state compile an official state
voter database by January 2006. Most states complied with HAVA by gathering
the voter files available from each individual county. States decided what
information to include, what restrictions to place on the use of their voter
database, and how much the database would cost. In the United States,
several companies have merged state voter information with commercially
obtained data to create comprehensive voter databases that include a
plethora of personal details on each voter. These companies often provide
United States Voter Files to statutorily permitted or otherwise
non-restricted users."*

...Thus, there are numerous state-wide databases to be found, but no
centralized repository of voter data.

At first glance this is kind of staggering to me considering how vast the
Federal Government is. But upon further inspection, it makes perfect sense,
as the potential for abuse of such a repository would be so great, that
mustering the political will to create one would probably have been quite
difficult. Thus, such a resource has (apparently, ostensibly, "officially"
and to the best of our knowledge) never been built. - I qualified that
statement as I am almost willing to bet that *private *repositories have
indeed been secretly compile by the likes of *Diebold*, et al. The fact that
this has never been done is is a double edged sword with a lot of
implications. From a security / privacy-risk standpoint (concerns that are
not without precedent<http://www.spamfighter.com/News-16708-Malicious-Program-Compromises-Database-of-Maines-Voter-Registration.htm>),
it is encouraging in the sense that it indicates our collective values in
rejecting totalitarianism and abuse of power. However, it is also a bit
discouraging in the sense that it seems to indicate a lack of cooperation or
coordination in protecting democratic freedoms.

*So, from where I'm standing, the whole issue of VRDBs is segmented thus:*

* 1)* The need to ensure a reliable, accurate means of securing and
authenticating voter identities. (*logistic*)

* 2) *The software that #1 (above) would need to run under (*technical*)

I've already addressed my thoughts on #1 above. Ad for #2, while there does
not appear to be an existing Open Source solution, there are numerous
commercial packages available. With politics these days being so thoroughly
clouded by money, special interests and lobbyists, it almost goes without
saying that a 'private' solution is the worst possible approach. Here are
the ones that I've unearthed:

 - *VoteBuilder* <http://www.votebuilder.com> from:
*NGPVAN<http://www.ngpvan.com>
*
 - *AccuVote<http://www.premierelections.com/secure_solutions/voting_equipment.html>
* from *Premier Election* (*front for Diebold*)
 - *ES&S <http://www.essvote.com/HTML/home.html> *from *Election Systems &
Software Inc.

...There are more, but I don't feel like listing them because - as far as
I'm concerned - they are all part of the problem.

To sum all of this up, I would be very interested in working on some sort of
shared / collaborative VRDB (I am henceforth claiming that term for this use
- Avast be damned). The same goes for mirroring and shared
issue-identifiers. My only concern about any of this would be the potential
for developing another political 'monoculture' such as the one we seem to
have now. I personally believe that the best hope for protecting democratic
freedoms lies in nurturing debate and offering a voice to divergent points
of view.
*
*In answer to your question regarding Metapolitik.org:*
*
"I have the impression that a user's vote is expressed as an RGB colour
that is automatically calculated (output) based on some description of
interests supplied by the user (input).  Is that correct?  If so, can
the colour somehow vary from issue to issue (say a foreign policy
issue vs. domestic), or is the same vote applied to all issues?"*

*First, some background:*

The entire project is based on my observation that the 2-axis, linear,
political 'spectrum' (as advanced by the Nolan chart and others) is
inadequate to describe the complex positions that an individual or group may
take on any particular issue. I believe that this shortcoming stems from a
'dualistic' approach to political debate which attempts to reduce all
dialogue into a 2-option, either-or scenario. Much like the deficiencies
addressed in your draft, the framing of political debate along a single axis
whereby the voter must choose between one of two polar choices, leaves a lot
to be desired (just as the closed-process, two-party electoral system in
which one or the other of two competing and wholly entrenched political
parties is - to put it lightly - less than democratic). Thus, unlike the
Nolan chart which plots political leanings across a 2-axis (X,Y) chart,
Metapolitik charts these positions accross 3-axis (X,Y,Z) chart. Thus adding
a 'third option' for those times when the choices that present themselves
are either undesirable or inaccurate. All of the published information on
this system can be found here:

 - Nutshell <http://metapolitik.org/content/nutshell>
 - Introduction <http://metapolitik.org/content/introduction>

So yes, voter's 'leanings' on issues would be ascertained via some sort of
questionnaire that would attempt to place them on the RGB chart in one of 3
'camps'. This process would also indicate what areas or issues in which the
voter shares common ground with competing camps. Americans Elect uses a
similar setup but I am very critical and distrustful of that whole project
for reasons that I explain
here<http://metapolitik.org/content/american-select-0>
.

*Sorry this was so long.*


~Conan
godspeed2048 at gmail.com
conan at metapolitik.org


On Wed, Oct 19, 2011 at 7:17 PM, Michael Allan <mike at zelea.com> wrote:

> Welcome Conan,
>
> Thanks very much for looking at my theory draft.  It points to a bunch
> of problems in society that are hidden in plain sight (as you suggest)
> and to their cause in the physical separation of elector and ballot.
> But it does not advocate for any particular solution such as direct
> democracy (I sometimes do, but the theory does not. :-).
>
> I have a question about Metapolitics.  But first I wanted to suggest a
> few possible paths for collaboration between projects.  We (I and my
> colleagues here) think that collaboration such as this is the way of
> the future, and maybe you agree:
>
>  (a) Sharing a voter registration framework.  Such a framework defines
>     standards for identifying users and authenticating them as
>     voters. It is mostly about voters, not users.  So it defines
>     things like registration and authentication in electoral
>     districts; proof of residence or organizational membership; the
>     compilation of voter lists; and so forth.  It does not define
>     registration and authentication of users, as such, so it is not
>     comparable to OpenID or OAuth.
>
>  (b) Sharing issue identifiers.  An issue would be like the adoption
>     of a policy initiative, and all the work that went into that
>     effort from the moment it was conceived.  Identifiers for such
>     issues can be shared across projects.
>
>  (c) Vote mirroring.  Vote mirroring is the active replication of a
>     vote between two vote-servers, in which the original vote is
>     shadowed by a mirror image on the other.  The vote-servers need
>     not have much in common (except a, b) and may employ dissimilar
>     voting methods.  Mirroring works by translation and is therefore
>     robust in the face of information loss.
>
> > The voting portion of this the (currently being developed with the
> > Drupal Voting API) will utilize a unique graphical output (currently
> > being developed in Processing) of a hexadecimal calculator (Perl)
> > that will determine a user's political 'colors' on a 3-Axis system
> > whereby the colors: red (conservative), green (progressive) and blue
> > (liberal) intersect / overlap (additive color model) to form one of
> > 3 secondary colors: cyan, magenta and yellow (or: white, where all 3
> > colors overlap - see Metapolitik Logo). Thus, only overlapping
> > colors constitute 'consensus' and only upon 'consensus' can policy
> > pass.
>
> I have the impression that a user's vote is expressed as an RGB colour
> that is automatically calculated (output) based on some description of
> interests supplied by the user (input).  Is that correct?  If so, can
> the colour somehow vary from issue to issue (say a foreign policy
> issue vs. domestic), or is the same vote applied to all issues?
>
> I apologize if my question is already answered in your docs.
>
> --
> Michael Allan
>
> Toronto, +1 416-699-9528
> http://zelea.com/
>
>
> Conan Duke wrote:
> > Michael,
> >
> > I have been reading these threads back and forth for a few weeks now,
> hoping
> > to glean some deeper technical understanding of the Votorola Engine and
> how
> > it might possibly be integrated into other software. I was not however,
> > expecting to find an impromptu digression into a stream of consciousness
> > critique of the structural validity of electoral causality and outcome.
> > Thank you.
> >
> > You seem to be advocating a more 'direct' form of democracy in which the
> > voter (the active decider) determines the outcome of policy, rather that
> the
> > voter determining the outcome of a race between 'representatives'. In my
> > reading of your post, you question whether it is advantageous or even
> > desirable to separate the interests of those being 'represented' with the
> > interests of those doing the representing. This strikes me as one of
> those
> > truths that is so simple, we often overlook it. A logical conclusion that
> is
> > so hidden in plain sight as to require an entire paper be written on it
> > simply to prove that it might be accurate.
> >
> > In other words, I already agree with your conclusions from just this
> initial
> > sketch, as these are observations / lamentations are similar to my own.
> > Looking forward to a first draft of your paper.
> >
> > All of which this brings to mind the whole purpose of my subscription to
> > this list in the first place:
> > I am currently developing of a next-generation, deep democratic, policy
> > engine.
> >
> > Since everyone on this list is here because they've expressed an interest
> in
> > this sort of thing, I will share some of it:
> >
> > I use the phrase 'policy engine' to distinguish this concept from a
> 'voting
> > engine' in that it's architecture is far more reminiscent of a 'Wiki'
> than
> > an online 'Poll'. In other words, participants are encouraged to not only
> > 'vote' directly on policy proposals, but they are encouraged to develop,
> > submit and maintain their own pieces of virtual legislation. MediaWiki
> (or
> > similar engine) is the obvious choice for the 'document' portion of the
> > platform.
> >
> > The voting portion of this the (currently being developed with the Drupal
> > Voting API) will utilize a unique graphical output (currently being
> > developed in Processing) of a hexadecimal calculator (Perl) that will
> > determine a user's political 'colors' on a 3-Axis system whereby the
> colors:
> > red (conservative), green (progressive) and blue (liberal) intersect /
> > overlap (additive color model) to form one of 3 secondary colors: cyan,
> > magenta and yellow (or: white, where all 3 colors overlap - see
> Metapolitik
> > Logo). Thus, only overlapping colors constitute 'consensus' and only upon
> > 'consensus' can policy pass.
> >
> > Much of this is laid out here: http://metapolitik.org
> >
> > [Introduction]
> > [Nutshell]
> >
> > ...Although the bulk of the original design remains unpublished.
> >
> > My plan is to develop these features 'on the fly' and to then roll them
> out
> > as they become functional.
> > Once there are enough core features for usability, I will start taking
> input
> > from the community as to what features and/or directions the design needs
> to
> > take.
> >
> > In the meantime, critique and comment are welcome at all times.
> >
> >
> > ~Conan
> > conan at metapolitik.org
> > godspeed2048 at gmail.com
> _______________________________________________
> Votorola mailing list
> Votorola at zelea.com
> http://mail.zelea.com/mailman/listinfo/votorola
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zelea.com/list/votorola/attachments/20111023/8d242b95/attachment.html>