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 <a href="http://www.spamfighter.com/News-16708-Malicious-Program-Compromises-Database-of-Maines-Voter-Registration.htm">precedent</a>), 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: - <a href="http://www.votebuilder.com">VoteBuilder</a> from: <a href="http://www.ngpvan.com">NGPVAN</a> - <a name="accuvoteos" id="accuvoteos"></a><a href="http://www.premierelections.com/secure_solutions/voting_equipment.html">AccuVote</a> from Premier Election (front for Diebold) - <a href="http://www.essvote.com/HTML/home.html">ES&S</a> 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: - <a href="http://metapolitik.org/content/nutshell">Nutshell</a> - <a href="http://metapolitik.org/content/introduction">Introduction</a> 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 <a href="http://metapolitik.org/content/american-select-0">here</a>. Sorry this was so long. ~Conan <a href="mailto:godspeed2048@gmail.com">godspeed2048@gmail.com</a> <a href="mailto:conan@metapolitik.org">conan@metapolitik.org</a> <div class="gmail_quote"> On Wed, Oct 19, 2011 at 7:17 PM, Michael Allan <<a href="mailto:mike@zelea.com" target="_blank">mike@zelea.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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, <a href="tel:%2B1%20416-699-9528" value="+14166999528" target="_blank">+1 416-699-9528</a> <a href="http://zelea.com/" target="_blank">http://zelea.com/</a> 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: <a href="http://metapolitik.org" target="_blank">http://metapolitik.org</a> > > [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 > <a href="mailto:conan@metapolitik.org" target="_blank">conan@metapolitik.org</a> > <a href="mailto:godspeed2048@gmail.com" target="_blank">godspeed2048@gmail.com</a> _______________________________________________ Votorola mailing list <a href="mailto:Votorola@zelea.com" target="_blank">Votorola@zelea.com</a> <a href="http://mail.zelea.com/mailman/listinfo/votorola" target="_blank">http://mail.zelea.com/mailman/listinfo/votorola</a> </blockquote></div>