Upgrade Democracy Report
Keenan Dakota
To the attendees of the Contact Summit 2011-- One of the four goals that you voted on (with your little red dots) was to Upgrade Democracy. This is an initial report from me, Keenan Dakota, one of the working group participants at all four meetings and some post-summit gatherings
If you want to add your name to the email list to receive updates on the progress of this project go to re http://upgradedemocracy.org/ . The contact person for the Upgrading Democracy conference in San Francisco spring of 2012 is Micah Daigle at micah...@gmail.com . The contact person for the Democracy Hackathon in Virginia 2012 April 28 to May 5 is Keenan Dakota at kee...@twinoaks.org. (see more details at the end of this post)
WARNING: Lots of words were said at the four different meetings about this topic. All of what follows is a provocation. Rather than present the many, many opinions, this paper comes down on one side of many issues about which people expressed opinions and, often, disagreement. Don't be intimidated. If you disagree, reply and make your case!
Linguistic notice: The terms user, site user, and citizen are used interchangably.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Contents of this document:
A- Summary of concepts
Summary of the concept for everyone
Summary of the concept for hackers
Similar web sites
Candidate “X”
B – Architecture and Protocols of the website:
Goal
Scale matters
No sock puppets
The quality of the user
Proxy voting
Transparency
Home page
Mentor system
Comments
The evolution of legislation
Voting systems
Gamification
C - Unsolvable problems:
Ignorance, apathy and time
the influence of money
legislation changes, voters change their minds
summary of the outcome of legislation
dis-empowered minorities
budgeting, implementation, and feedback
making money from the site
D - Details of next conferences:
San Francisco
Virginia
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Is Ruby on Rails the preferred application framework for this web site? Please comment. We need to answer this question before we even start!
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
A- Summary of concepts
Summary of the concept for everyone:
The world we can collectively imagine is abundant and peaceful; all people are happy, healthy, and productive. We can imagine this world, but for some reason we haven't yet created it. Many, many brilliant and powerful ideas don't catch on. Even when most people agree that, yes, this is a good idea, that idea frequently doesn't happen. We see that part of that problem comes from ineffective political processes. The wisdom of the people is not tapped in making policy decisions that effect everyone. We aim to fix that. We are designing a powerful web-based tool that will gather the best thinking of people, allow people to vote on the ideas the most want to see, polish them into actionable policy, and move these ideas through the legislative process until it becomes a final, implemented decision. Our goal is no less than to create a better world for everyone
summary of the concept for hackers:
Crowd sourcing has been proven to be powerful and effective. The aggregated wisdom of the people is consistently better than the wisdom of even the best-informed expert. Whatever country you might be reading this in, your government sucks. Government does not use crowd sourcing to make better policy. Those few enlightened places that do, don't do it very effectively. Lots of people are making attempts in this direction, to use current networking technology as a tool to improve governance. This idea is so popular that we can know that somewhere the breakout app is going to happen. We want to create that breakout app. Mainly because this work is very important—government everywhere provides friction to almost all innovation—but also because the architecture of the breakout app could have bad ramifications, so we want to make sure that the breakout app includes transparency, empowers all citizens, and allows users with similar interests to network with each other.
Similar web sites:
We are laboring in the same vineyard with many kindred spirits. If you are working on one of these other sites, we wish all of you great success in your desire to empower people. However, we see flaws in the designs of each of the sites that have been proposed or that are operational. If you like our proposals, please, steal our ideas. We will race you to be that breakout app! It is an international phenomenon:
In Brazil: e-democracia
In Sweden: Demoex
In Italy: Lista Participata
In Australia: Senator on line
In Iceland: Your priorities
In Canada: Public Policy Wiki
The most recent additions are:
Re-invent Democracy by Nancy Bordier
PopVox by Marci Harris
signOn.org at moveon.com
WeThePeople at White House.gov
There are more of these sites popping up almost every week.
Candidate “X” :
One application of this website is to allow candidates to run for office by commiting to submit legislative questions to the people. This is possible and it is already happening:
from Wikipedia:
Demoex, an appellation short for democracy experiment, is a local Swedish political party and an experiment with direct democracy in Vallentuna, a suburb of Stockholm, Sweden.[1] It uses the Internet to make it possible for any member to participate in the local government. Demoex has a representative in the municipal council, who votes in the council according to a poll that is held beforehand on the website of the party. This is unlike traditional representatives, who vote according to their own views or their party's views. Every Vallentuna resident older than 16 years can register on the website to vote; anyone in the world can take part in the debates, if they can write in Swedish. Voters do not have to vote on all issues; the fewer votes on an issue, the more weight each vote carries. To boost participation, the party allows users to choose someone to advise them on a particular topic.
Demoex was founded on March 6, 2002, and won a local election in the municipality Vallentuna that year. The Demoex representative is 19-year-old student Parisa Molagholi, elected on 4 November 2002 with 1.7% of the votes. She began serving as representative in 2003, and was re-elected in 2006 with 2.9% of the votes. Her success has astonished traditional politicians. The party's representative, Per Norbäck, was elected in 2010 with 1.76% of the vote. Demoex intends to become a national party and eventually an international party on the same principles.
...End of Wikipedia entry
B – Architecture and Protocols of the website:
Goal.
The overarching goal of this web site is to allow people to effectively aggregate their input on a particular policy proposal so that a final decision can be made. Decision-makers (legislators) must be able to post proposals on this web site and get accurate input from their constituents. Site users—citizens—must be able to give accurate, timely, and effective input on legislative proposals.
Success will look like this: candidates running for office will promise to vote the way that their constituents desire, based on input from this site; citizens will be able to propose, edit and vote on legislative proposals on this site; the proposals supported by a majority of citizens on the site will be presented to the legislature for a final vote of implementation.
Scale matters.
This web site will have different modules that operate at different scales. A group of 100 people will be able to plug in to a module that works for a group of 100 with lower security, less complexity, fewer safeguards etc. At the national level a very different module will be used.
Location based.
Site users will be able to find other citizens with similar interests. This function of the site will operate as a potent social network—users can find other people in the area who have the same passionate interests. These kindred spirits will likely gather together to promote their common interests. This is a safe way to meet with others, and no doubt friendships and relationships will blossom among these gatherings. The social networking capacity of this site is a powerful by-product of this web site and will drive traffic to the site. More, it contributes to the keystone concept that people working together for a common cause is essential for empowerment.
No sock puppets.
Crucial to the functioning of this site is prevention of sock puppets. Everyone must have a unique ID to the site. The only really safe way to do this, since we are talking about input on legislation, is through social security numbers. The site will assign each person a unique identity for use on the site. Are there other possible solutions to this problem?
The quality of the user.
Some users are ignorant, some users are apathetic and some users are very busy. While we all wish to have input from informed and engaged citizens, that's not going to happen. This site will allow three different lanes for giving input: Express Lane, Default, and Engaged Citizen.
The “Express Lane” is for the ignorant, apathetic, and busy user to give their input. The Express Lane only requires that the user click on a very quick survey of core values that person might hold. When a finalized piece of legislation is at the stage of final passage, then the Express user receives a message summarizing that piece of legislation and the site will guess how they might vote on it based on their stated values. Then the user may choose to cast their vote. This is lame input, but it's better than the current legislative system allows and it somewhat represents the interests of these citizens. Essentially, it allows people who hold a few very passionate ideals to participate easily.
The Default setting includes this Express Lane option, of course, but the user receives more frequent communication from the site about pieces of legislation that are being proposed, that their friends are supporting, whether supported legislation is rising or falling in support, whether written comments are receiving supportive comments etc. Unless there is an urgent vote, the user will only receive a maximum of one message a day—a summary of all of the actions that are relevant to that user's stated interests.
The Engaged Citizen allows for many messages from the site to be received daily. An engaged citizen also has the capacity to act as a proxy for other voters. Additionally, an engaged citizen has the option to choose the voting system that they will use on the web site (between, say, three different, but similar amendments to a piece of legislation).
Proxy voting
A citizen may allow another user to cast a vote for them—a proxy vote. When designating a proxy, a citizen will be given a list of options about the length of time of this proxy, the scope of the proxy (This piece of legislation only, this topic only, city council only, statewide only, or, all issues). Whenever a vote is cast by a proxy for a citizen, the citizen receives a message about the vote. A user can undesignate a proxy vote at any time.
An Enaged Citizen may gather an unlimited number of proxy votes. The scale of their proxy voting power will be represented by an icon that will attach to any comments that the proxy leaves. A proxy may also designate some or all of their proxy votes to another user. These may also have specific limitations of time, topic or local, state or national level. On the other hand, a citizen may only have up to ten other people voting their proxy. And each proxy must be ranked from one to ten in order of most trust so that if more than one proxy votes on an issue, the site will know whose vote is the one that counts.
It is possible, as an issue gains attention and momentum, that a citizen wants to cast their own vote—that's OK. Since every voter has only one identity on the site, the site will recognize the voter and notify them that they have already voted by proxy (if that's the case). Or, if the proxy votes “wrong” the citizen may change their vote (up until the moment of the final vote count). If a proxy attempts to vote and their citizen has already voted, the proxy will be notified at that time ( “Jill Randomperson has already cast her vote on this issue”) and the vote won't count twice. This means a couple of different things. Some proxy voters will actually have fewer votes than they thought they had. It also means that the user can give their proxy to lots of proxies in a tree of hierarchy and more than one proxy may attempt to vote that citizen's vote, but only the person at the closest hierarchy level will count.
Transparency:
It is fundamental that every citizen be able to cast a private vote. So votes are private, but every other interaction on the site is public and visible. Each comment a user leaves can be clicked on and links to every other comment that user has left. Every input (we won't call it a vote so as not to be confusing) on other people's comments of support or opposition is also clickable and links to every other input that person cast. The default assumption of the site is transparency of discussion on issues.
Home page:
The point when many people are lost is as newbies to a site. The site will have an easy and unintimidating front page for new visitors. The home page will have moving entries of “trending legislation” and “Joe citizen wants you to support this legislation” and “legislation that you may be interested in.” at this stage the visitor doesn't have to sign in. The visitor can click on legislation, they can read people's comments, they can track the comments of various individuals, in general they can wander all over the site. If the visitor clicks on “support” for a piece of legislation they are asked to sign in and also asked if they would like to “meet” someone else interested in supporting this idea. If they answer yes, then someone who has earlier volunteered to be a mentor is sent a message to get in touch with the visitor. In an ideal world someone who has volunteered to mentor will be online at that moment and will respond to the request.
Once someone signs in they are asked “What one change do you most want to see in the world?” And the words the user writes will send them to legislative proposals that have already been written, and they are offered “Do you want to write a new proposal?” If there isn't enough there to keep them on the site, then they will be given links to other, already existing, political and social organizations that are working on similar issues.
The new person is also asked “Do you want to see what proposals people in your area are supporting?” Later the new user is asked what type of user track they want to be on, what issues they care about, etc. These questions will pop up after the new user has been on the site for a period of time. Also popping up will be short tutorials on how to use the site. Various aspects of gamification will make these early stages more compelling, but these are covered in a moment under “gamification.”
Mentor system.
A person can click on and bring up a list of topics and express an opinion. Within each topic they can ask for a mentor (or one can be assigned to them automatically if they seem to be having trouble). This is an actual person who has expressed interest in this issue and who would, obviously, be very motivated to mentor people through the site to get them to express support for that issue.
Comments.
Of course it will be possible to leave comments on any proposals. Those comments that get the most votes of support will rise to the top of the comments list. The most supported commenters gain status points.
The evolution of legislation.
As legislation moves through the legislative process, it gets changed, it gets amended, the focus can shift in ways that change a citizen's support into opposition. As legislation changes, updates will be sent to users. And, of course, once legislation gets passed the citizen will receive notification that legislation that they voted for (directly or by proxy) passed.
Voting systems.
Within the site when a decision needs to be made, for instance between the wording of one similar amendment versus another similar amendment, the site will have an embeded voting system that allows users to rank their choices. The preferred voting methods are the Schulze method, or Tideman's Ranked Pairs, or a Condorcet-Hare hybrid. One thing the voting system provides is if the first preference is eliminated, the next preference is used. Engaged Citizens will have the option to select their own voting system.
Gamification.
Crucial to the success of this site will be return users and engaged users. The internet is currently littered with sites that support the idea of gathering people's input to help get laws changed. The eventual killer app will have gamification. On this site when a user logs on they will be given a random number of flags of their country that they can use to indicate support for comments that they read. These flags disappear at the end of the session.
Citizens will gain status as they contribute to building the site by doing things like:
Write proposed legislation that other people support.
Get friends to sign up for the site.
Make a comment that other people support.
Create a link that other people support.
Post information and links to the site on other social media sites.
Writing summaries of legislation
Extra powers that can be gained are:
highlighting and advertising a certain piece of legislation
Being able to be a proxy for other voters
Being able to be a mentor
getting additional flags to support people's comments
Each time a user returns to the site, a national flag on the home page will be built step-by-step and will eventually get larger and wave with vigor. As they gain more status they can choose which other flags to fly.
Users will be notified about where they stand in comparison to other users in number of supportive flags received.
The site will proudly announce legislation that was proposed on the site that has been passed.
C - Unsolvable problems:
It is useful to keep the current legislative processes in mind when considering this alternative, although there may be some flaws in this idea's implementation, it will be way better than the system we've got now. It is useful, I think, to acknowledge that there are some fundamental problems that can't be solved, or that attempting to solve these problems can create much, much worse problems.
-- Ignorance, apathy and time
Some people are just plain ignorant and they deserve a vote, too. More often people are busy or apathetic, so they want to give their opinion in as short a time as possible. Inevitably these will be poorly informed votes. There is no way around this. It is impossible to create perfect legislation because we don't have perfect people, but we can create decent, effective, and fair legislation, because mainly people are decent and fair.
-- The influence of money
Moneyed interests have a tremendously disproprtionate sway over legislation at the moment. This web site will disempower the moneyed interests that operate at odds to the will of the people. However, moneyed interests are not going to roll over and go away. People with loads of money will find ways to game this system, too, as every other system has been gamed. This web site will tip things far in the direction of empowering people and disempowering the worst evil practices of moneyed interests, but it's not possible to create a totally non-biased voting technology.
-- Legislation changes, voters change their minds
A proposal changes as it nears passage. People change their minds about issues. It is very difficult to get exactly the legislation that people want. This site will make the legislative process infinitely more response to the will of the people, but that will can be mis-read, so there still will once this web site is fully operational and widely adapted, be legislative errors made. It is not a flaw in the system, but an inherent conflict between the need for more time needed to gather and share information and a universe where time is finite.
-- Summary of legislation
Legislation is vast and complex. There will need to be a summary of every piece of legislation and amendment. Having the proposer of legislation also being the summarizer invites bias. Like wikipedia, there will need to be open access to providing legislative summaries. Summaries and summarizers will be graded so users can know which ones are more trustworthy.
--Dis-empowered minorities
The final yes/no decision on legislation must be a majority rule decision. On small-scale groups, consensus—or something other than majority rule—is possible, arguably up to as many as 5,000 people. But the site will set 250 people as the limit beyond which majority rule will be used. There is little systemic protection for minority opinion on this site.
-- Budgeting , implementation, and feedback
Even passing a new law doesn't mean that anything actually changes. At the site where the new legislation resides will be an implementation and feedback forum so people can report on results over time. A year after any new legislation is passed, the user will receive a message asking “Did the passage of the legislation you voted for, (“HR 209A blah blah blah” ), result in the changes you had hoped? If not, come back to the site and make a new proposal.”
-- Making money from the site
We're all working for free. There will not be money to be made, but there may be occasional pleas for donations to help take care of people who are maintaining the site.
D- Details of next conferences:
Upgrade Democracy conference in San Francisco. The conference will be held spring 2012. If you are interested in helping organize this conference contact Micah Daigle at micah...@gmail.com.
Democracy hack-a-thon In Virginia, at Twin Oaks Community near Charlottesville, Virginia, Saturday April 28th through Sunday May 5th . There are only 20 spaces. The goal is the development of the site proposed here. Only programmers and designers need apply. The cost to each participant is $50 for all nine days. (We have received a generous grant to get this to happen.) Applications must be received by December 21st. Everyone will be notified if they have received a slot by December 31st. It is possible to attend for less than the full nine days, but it is $20 more for every day less than the full nine days—that's right, the shorter your stay, the more it costs. If you can't come at all, send a check for $300 and we'll call it even. (That last sentence was a joke.)To apply write to kee...@twinoaks.org and you will receive an application by email. A room and all meals are included. All dietary preferences will be accommodated. Food is also provided between meals (including cooking up your own meals if you are so moved). Some rooms may be shared with another conferee.
Samuel Rose
It's my experience that if you are approaching the design of your
application in a way that is mapping the modeling of objects and
relationships to the activities you hope people will be doing, then a
MVC framework like Ruby on Rails or Django project is a good fit, and
very forgiving if you need to re-adjust on the fly. There's also a lot
of good convention to follow, documentation, online troubleshooting,
and automation around Ruby on Rails in particular. So, for those
reasons there's a good chance that it is a good choice if you are
starting out a project to build a complex web application. I don't see
any specific reason in anything you've shared about why you shouldn't
use Rails, either.
--
--
Sam Rose
Hollymead Capital Partners, LLC
Cel: +1-(517)-974-6451
email: samue...@gmail.com
http://hollymeadcapital.com
http://p2pfoundation.net
http://futureforwardinstitute.com
http://socialmediaclassroom.com
"The universe is not required to be in perfect harmony with human
ambition." - Carl Sagan
Fabio Barone
very intrigued to read so many details already about one of the winners of the contactcon prize!
First off, congrats!
It surely sounds like a great project and a great winner.
Only one comment:
I see you already have changed a slight wording between two different posts
about "competing" sites. incidentally, those in fact each run at different places.
So maybe it is the killer-idea which is key, not a single killer-app implementation.
"Nothing is as powerful as an idea whose time has come". (V. Hugo),
as you already imply.
As, sure, some may come with flaws, but some of these flaws might be cultural
differences which we should respect. In other words, decentralization
may come up with different solutions and customizations. And we all
can learn from each other.
Having said that, great work! Wishing all the best for this project
Samer
It's my experience that if you are approaching the design of your> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
> Is Ruby on Rails the preferred application framework for this web site?
> Please comment. We need to answer this question before we even start!
>
> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
application in a way that is mapping the modeling of objects and
relationships to the activities you hope people will be doing, then a
MVC framework like Ruby on Rails or Django project is a good fit, and
very forgiving if you need to re-adjust on the fly. There's also a lot
of good convention to follow, documentation, online troubleshooting,
and automation around Ruby on Rails in particular. So, for those
reasons there's a good chance that it is a good choice if you are
starting out a project to build a complex web application. I don't see
any specific reason in anything you've shared about why you shouldn't
use Rails, either.
Without wanting to begin a flame war about it, I wouldn't support Rails but Java with the framework Google Web Toolkit. This allows developers to benefit from the many benefits of Java dev, but compiling in Ajax... which provides single-page rich apps that in general are much more powerful than typical Rails ones. Besides, in large projects the productivity is boosted, but this is just my opinion. I would try to get documented a lot before taking the decision though, as it's quite important.
--
Samuel Rose
No flame war here. I don't develop with Java or Google Web Toolkit at
all, but I can imagine it would work. I'm sure the lead developers
will have the greatest influence on this choice, and I wish them good
luck on this worthy project!
mi...@zelea.com
I learned of Upgrade Democracy on the grapevine and it eventually led
me to this thread. I have some experience in designing the kind of
app that Keenan describes, so I wanted to chime in with some thoughts,
particularly in reply to Keenan, Fabio and Samer.
Keenan Dakota wrote:
> It is fundamental that every citizen be able to cast a private
> vote. So votes are private, but every other interaction on the site
> is public and visible. Each comment a user leaves can be clicked on
> and links to every other comment that user has left. Every input (we
> won't call it a vote so as not to be confusing) on other people's
> comments of support or opposition is also clickable and links to
> every other input that person cast. The default assumption of the
> site is transparency of discussion on issues.
I think a private vote is problematic for two reasons: credibility and
sociality. The credibility problem has to do with popular perception,
more than any technical fact; methods of authenticating private votes
in online systems *do* exist, but none is so simple and transparent as
the method of full disclosure available to public vote-servers. Any
lingering doubt of the system that is sufficiently widespread would
offer fertile ground for attack campaigns.
Another problem is the de-socializing of the medium. The human
attractions are largely eliminated if the users can no longer identify
each other as voters. Voting is so crucial to the interactive process
of consensus making that it's difficult to mediate without disclosing
identities. Maybe a team sport offers a good analogy to illustrate
the problem. A contrivance that somehow hid the identities of the
players from each other would detract from the experience. If nothing
else, the game would be less interesting to play. Any league that
enforced privacy would therefore lose players to one that allowed for
a more natural social interaction.
Fabio Barone wrote:
> So maybe it is the killer-idea which is key, not a single killer-app
> implementation. "Nothing is as *powerful* as an *idea* whose time
> has come". (V. Hugo), as you already imply. As, sure, some may come
> with flaws, but some of these flaws might be cultural differences
> which we should respect. In other words, decentralization may come
> up with different solutions and customizations. And we all can learn
> from each other.
I strongly agree. Those "flaws" might be cultural differences as you
say, or personal differences among groups of users with special needs,
or even novel technical ideas that others have yet to recognize. It
would be a shame if everyone was herded into the same voting software,
like it was Facebook or Twitter. Your remarks remind me of Mark
Murphy's prize essay, 'The "killer app" of public participation'.
Here are his two leading principles for such an app: *
1. Openness. Just as anyone can host a blog, run an e-mail server,
or put up a web application, anybody should be able to build
tools and participate in the aggregation of the resulting data.
Conversely, if the aggregation only happens on a single,
proprietary site, trust is broken due to lack of transparency.
Everyone must be able to cast a vote on any issue. Determining
which votes are from people with “a horse in the race” must be
done after the fact, since screening beforehand could be applied
indiscriminately and shut down useful opinions.
2. Public. Not only must issues be publicly visible, but so must
the votes, in the same way that blog entries and comments are
publicly visible. This is the key to supporting the first
principle. Because the votes are public, anybody can build an
aggregator to report results or verify the reported results of
others. However, if nobody can validate the voting, trust is
broken (witness the hullabaloo over voting machine flaws).
We're planning to use the technique of vote mirroring among sites to
encourage this kind of openness, to preserve technical diversity and
to keep the playing field level. For technical details, please see:
https://lists.takethesquare.net/pipermail/occupy-dev/2011-November/000071.html
Samer wrote:
> Without wanting to begin a flame war about it, I wouldn't support
> Rails but Java with the framework Google Web Toolkit. This allows
> developers to benefit from the many benefits of Java dev, but
> compiling in Ajax... which provides single-page rich apps that in
> general are much more powerful than typical Rails ones. Besides, in
> large projects the productivity is boosted, but this is just my
> opinion. I would try to get documented a lot before taking the
> decision though, as it's quite important.
Java is attractive for us too, simply because we use it at the back
end. That's partly why we chose GWT for the front end. We only have
a rough prototype as yet, so the nicest views are still the mockups:
http://zelea.com/project/votorola/a/xf/vote/_/3.xht
For more info, plus links to the running demo (partly functional),
please see: http://zelea.com/project/votorola/a/xf/
* Mark Murphy. 2008. The "killer app" of public participation.
*In* Rebooting America. Edited by Allison Fine, Micah L. Sifrey,
Andrew Rasiej and Joshua Levy. Personal Democracy Press.
http://rebooting.personaldemocracy.com/book-chapter-rebooting/killer-app-public-participation
--
Michael Allan
Toronto, +1 416-699-9528
http://zelea.com/
Samer
http://kune.beta.iepala.es
and honestly, to build something like that is impossible with Rails... and it's too big to just face it with javascript.
Cheers,
Hellekin O. Wolf
> Dear all,
>
> I learned of Upgrade Democracy on the grapevine and it eventually led
> me to this thread. I have some experience in designing the kind of
> app that Keenan describes, so I wanted to chime in with some thoughts,
> particularly in reply to Keenan, Fabio and Samer.
>
> Keenan Dakota wrote:
>
>> It is fundamental that every citizen be able to cast a private
>> vote. So votes are private, but every other interaction on the site
>> is public and visible. Each comment a user leaves can be clicked on
>> and links to every other comment that user has left. Every input (we
>> won't call it a vote so as not to be confusing) on other people's
>> comments of support or opposition is also clickable and links to
>> every other input that person cast. The default assumption of the
>> site is transparency of discussion on issues.
>>
> I think a private vote is problematic for two reasons: credibility and
> sociality.
for at least two reasons.
Privacy and intimacy. Privacy first: in some places, voting against the
dominant party can get you killed. Imagine you're in Mexico, in Vera
Cruz, where people wear masks--why, but why?, and you want to vote
against the candidate of the drug cartels. If your vote is *not*
private, you have two choices: get killed, or vote against your will.
Next, intimacy: in France, we have a rule regarding religion, it's a
republican rule, and it's called "laicity". It means that religion is
regarded as a private matter, and you might be of any obedience,
including an atheist, and not be worried about it in your public life.
The same goes for "publicity" and "transparency" in democracy, and the
vote, as brilliantly demonstrated by the #15M and #OWS movements.
Whatever your political opinion, I want to work with you because we're
cooperating on some public issues. I don't want to know where your
political opinion leans, because it's not a question of political
parties, but a political issue. Hence, I want to be able to address the
citizen, not the partisan. Whether I would vote the same as you is not
relevant, and should not influence my interaction with you, the
individual citizen. That's why private voting is necessary. When it
doesn't exist, "externalities" become influential.
Cheers,
==
hk
Samer
+1
Michael Allan
> ... I think a private vote is *necessary* ... in some places, voting
> against the dominant party can get you killed. Imagine you're in
> Mexico, in Vera Cruz, where people wear masks--why, but why?, and
> you want to vote against the candidate of the drug cartels. If your
> vote is *not* private, you have two choices: get killed, or vote
> against your will.
You speak of a situation in which freedom of expression is denied
because the citizens are too frightened to voice their opinions in
public. But I think this situation is itself incompatible with any
substansive democracy or political freedom.
I believe the same is true for the monopoly that Keenan Dakota, Micah
Daigle and the Dynamic Democracy Initiative are apparently aimed at.
Their Upgrade Democracy project is "racing" to build "the architecture
of the breakout app" that will save us from the "bad ramifications" of
alternative choices. But despite their good intentions, I feel they
are promoting the wrong kind of race. The prize should not be one
that saddles us with a monopoly of voting media, but rather one that
frees us from any such monopoly. We citizens are capable of
safeguarding our own freedoms of speech and political participation by
our own efforts, provided only that we have an unrestricted choice of
the underlying media. *
> Next, intimacy: in France, we have a rule regarding religion, it's a
> republican rule, and it's called "laicity". It means that religion
> is regarded as a private matter, and you might be of any obedience,
> including an atheist, and not be worried about it in your public
> life. The same goes for "publicity" and "transparency" in
> democracy, and the vote, as brilliantly demonstrated by the #15M and
> #OWS movements. Whatever your political opinion, I want to work
> with you because we're cooperating on some public issues. I don't
> want to know where your political opinion leans, because it's not a
> question of political parties, but a political issue. Hence, I want
> to be able to address the citizen, not the partisan. Whether I
> would vote the same as you is not relevant, and should not influence
> my interaction with you, the individual citizen. That's why private
> voting is necessary. When it doesn't exist, "externalities" become
> influential.
I'm not sure I understand this kind of "intimacy", or how it bears on
public voting. Can you provide a specific example where a public vote
has harmful effects in this regard?
* Upgrade Democracy is discussed in this forum (invite only):
http://www.facebook.com/groups/upgradedemocracy/
It is owned by the Dynamic Democracy Initiative, as described here:
http://www.facebook.com/groups/upgradedemocracy/docs/#!/groups/upgradedemocracy/doc/167907396632536/
It is a coalition. It lists 19 organizations as "part of the
Upgrade Democracy community", which implies they are part of the
coalition. But reading it more carefully, they is not the case:
http://www.facebook.com/groups/upgradedemocracy/#!/groups/upgradedemocracy/doc/167918099964799/
Who are the members of the coalition, does anyone know?
--
Michael Allan
Toronto, +1 416-699-9528
http://zelea.com/
Travis
On Nov 22, 2:37 am, Michael Allan <m...@zelea.com> wrote:
> Dear Hellekin,
>
> > ... I think a private vote is *necessary* ... in some places, voting
> > against the dominant party can get you killed. Imagine you're in
> > Mexico, in Vera Cruz, where people wear masks--why, but why?, and
> > you want to vote against the candidate of the drug cartels. If your
> > vote is *not* private, you have two choices: get killed, or vote
> > against your will.
>
> You speak of a situation in which freedom of expression is denied
> because the citizens are too frightened to voice their opinions in
> public. But I think this situation is itself incompatible with any
> substansive democracy or political freedom.
All models are wrong; some models are useful. The software should be
configurable and encompass both anonymous and public voting otherwise
it will miss some targets.
I also believe it is possible to publish data that allows everyone to
verify that
* everyone who voted only voted once (or within the constraints of the
model)
* voters were within a pool of eligible individuals (eg citizens)
* each vote was indeed the respective voter's choice
while maintaining anonymity.
Michael Allan
> ... The software should be configurable and encompass both anonymous
> and public voting otherwise it will miss some targets.
I agree, the choice between public and private is best left to the
user as a personal choice. Last year, we sketched the design of a
privacy option that could be implemented in the voter registry, as
opposed to the voting system per se:
http://zelea.com/w/User:Mike-ZeleaCom/Streetwiki#Proxy_blind
The user has two identifiers: (1) a registration identifier rID that
is associated with his/her real name and address, and (2) a voter
identifier vID. The equivalence rID = vID is kept a secret. This
approach is nice because it doesn't touch the voting systems (many)
but only the residential voter registry (one). It has problems
however, as noted there.
Another way to combine the strengths of public and private voting is
through staging in separate systems. In the electoral application of
this, public voting is allowed in the run-up to the election (primary
electoral system) culminating in a final secret ballot on election day
(state electoral system). This has other benefits, too. See item c:
http://zelea.com/project/votorola/d/theory.xht#fn-2
In the legislative application, the primary stage (basically what
Keenan proposes) allows for public voting, while the secondary stage
(such as Parliament or Congress) typically allows for no voting at all
by the citizen. Here's a recent thread that discusses the general
primary/secondary split in the context of the Occupy GA, and beyond:
https://lists.takethesquare.net/pipermail/occupy-dev/2011-November/000123.html
> I also believe it is possible to publish data that allows everyone
> to verify that
> * everyone who voted only voted once (or within the constraints of
> the model)
> * voters were within a pool of eligible individuals (eg citizens)
> * each vote was indeed the respective voter's choice
> while maintaining anonymity.
Yes, and this is not disputed. Moreover if each voter freely chooses
his/her own voting method (public or private? cascade or condorcet?),
then us technicians needn't argue about which of these is best, as
though we knew! Instead we just implement all of them in our own
voting systems. Then we need only agree on the open framework that
levels the playing field and ensures a free choice among them.
Anyway, I just wanted to suggest this. It might sound like the
argument of a weak or unwilling competitor, but I think such an open
framework has a fighting edge that even Google or Facebook would fear.
--
Michael Allan
Toronto, +1 416-699-9528
http://zelea.com/
Keenan Dakota
Keenan
Travis
>
> The user has two identifiers: (1) a registration identifier rID that
> is associated with his/her real name and address, and (2) a voter
> identifier vID. The equivalence rID = vID is kept a secret. This
> approach is nice because it doesn't touch the voting systems (many)
> but only the residential voter registry (one). It has problems
> however, as noted there.
Interesting! But why does the equivalence need to be kept at all?
I'm envisioning a process where a bunch of citizens together generate
key pairs using gpg. Of course they keep their private keys secret
from each other, but in one transaction they submit their collection
of public keys to a registrar. The registrar notes that all citizens
in the list can not register another public key, but doesn't know
which key belongs to who. Votes are then signed with the private key
and submitted through some mechanism that avoids identification like
onion routing, or putting thumb drives into a hat. If you want to put
your John Hancock on your thumb drive you are free to do so.
>
> I think such an open
> framework has a fighting edge that even Google or Facebook would fear.
Always good to hear that someone is working on these problems.
Travis
Michael Allan
Keenan wrote:
> Thanks! This sounds great! I appreciate the time you put into
> writing this all out!
You're welcome. Congratulations on winning last month!
I have a question. Upgrade Democracy is an unusual project and I'm
uncertain how to approach it. On one hand, you're a coalition of
technical projects working to develop software. On the other hand,
you have no coalition members as yet, no software and no technical
designs. So your plan is to host a conference in the spring to build
the coalition, then gather 20 engineers at a private retreat to build
the software. Is this correct? Or do I misunderstand?
Travis wrote:
> Interesting! But why does the equivalence need to be kept at all?
> ... I'm envisioning a process where a bunch of citizens together
> generate key pairs using gpg. Of course they keep their private keys
> secret from each other, but in one transaction they submit their
> collection of public keys to a registrar. The registrar notes that
> all citizens in the list can not register another public key, but
> doesn't know which key belongs to who. Votes are then signed with
> the private key and submitted through some mechanism that avoids
> identification like onion routing, or putting thumb drives into a
> hat. ...
So instead of a simple equivalence of registrant identifiers (1), you
essentially propose an equivalence of groups (2).
(1) rID = vID
(2) rID * n = vID * n
where: rID is an ordinary registrant identifier, and
vID is a proxy identifier for private voting
The registrar knows that each rID in the left group is bound to a vID
in the right group, but does not know exactly which one; only the
registrant knows. This causes an interesting problem. To see it, we
must look at some details in the registry. Here are relations between
registration properties (left) and various formal identifiers:
Voter registry Vote-servers
====================== ===============================
name voter ID 1 (maybe public key)
\ /
address -- rID -- vID ----- voter ID 2
/ / \
electoral ---+ voter ID 3
districts
All of these relations are public except the proxy relation rID = vID.
This is kept hidden either by a proxy blind (secret of registrar and
registrant), or by group equivalance (registrant only). The problem
with the latter is that *some* registration properties (left) are
attached to both rID and vID. For instance, vote-servers must know
which electoral districts a given vID is entitled to vote in. Now
imagine a registrant (rID) updates his/her electoral districts. How
is this update propagated to the proxy vID when the relation rID = vID
is unknown to the system? Or if the registrant propagates it, then
who authenticates it?
BTW, this propagation of updates is one of the weaknesses of the proxy
blind design. Detection of identical updates between an rID and vID
could reveal the secret relation between them. This is where we gave
up on the design, at least for the time being. We currently implement
only public voting with full disclosure of all relations:
name voter ID 1 (maybe public key)
\ /
address -- rID ------------ voter ID 2
/ \
electoral voter ID 3
districts
I sometimes wonder whether *any* privacy scheme for online voting
would be solid enough in practice to warrant a promise to a vulnerable
person: this is safe. Or even whether it's a worthwhile design goal.
If it really is dangerous to express an opinion in public, then maybe
we ought to work on eliminating that danger at its source, rather than
dodging it with complicated workarounds.
--
Michael Allan
Toronto, +1 416-699-9528
http://zelea.com/
Keenan Dakota wrote:
> Thanks! This sounds great! I appreciate the time you put into writing
> this all out!
>
> Keenan
Douglas Rushkoff
Micah Daigle
4.
Travis
>
> Travis wrote:
> > Interesting! But why does the equivalence need to be kept at all?
> > ... I'm envisioning a process where a bunch of citizens together
> > generate key pairs using gpg. Of course they keep their private keys
> > secret from each other, but in one transaction they submit their
> > collection of public keys to a registrar. The registrar notes that
> > all citizens in the list can not register another public key, but
> > doesn't know which key belongs to who. Votes are then signed with
> > the private key and submitted through some mechanism that avoids
> > identification like onion routing, or putting thumb drives into a
> > hat. ...
>
> So instead of a simple equivalence of registrant identifiers (1), you
> essentially propose an equivalence of groups (2).
>
> (1) rID = vID
>
> (2) rID * n = vID * n
>
> where: rID is an ordinary registrant identifier, and
> vID is a proxy identifier for private voting
Sounds right. I appreciate your carefully laid out ASCII.
>
> The registrar knows that each rID in the left group is bound to a vID
> in the right group, but does not know exactly which one; only the
> registrant knows. This causes an interesting problem. To see it, we
> must look at some details in the registry. Here are relations between
> registration properties (left) and various formal identifiers:
>
>
> Voter registry Vote-servers
> ====================== ===============================
> name voter ID 1 (maybe public key)
> \ /
> address -- rID -- vID ----- voter ID 2
> / / \
> electoral ---+ voter ID 3
> districts
>
>
> All of these relations are public except the proxy relation rID = vID.
> This is kept hidden either by a proxy blind (secret of registrar and
> registrant), or by group equivalance (registrant only). The problem
> with the latter is that *some* registration properties (left) are
> attached to both rID and vID. For instance, vote-servers must know
> which electoral districts a given vID is entitled to vote in. Now
> imagine a registrant (rID) updates his/her electoral districts. How
> is this update propagated to the proxy vID when the relation rID = vID
> is unknown to the system? Or if the registrant propagates it, then
> who authenticates it?
I'm not imagining that updates are propagated at all. In fact, the vID
should be discarded after every vote to minimize the collection of
data around a vID. For example, timing of the submission of the vote
and means of transmission (key fob, tor, etc).
The weakness I see in the method I've described is selection of the
group to submit public keys for. The group would need to be as big and
diverse as possible, but small enough that everyone in the group knows
for certain there is no pollution of the public keys submitted.
>
> BTW, this propagation of updates is one of the weaknesses of the proxy
> blind design. Detection of identical updates between an rID and vID
> could reveal the secret relation between them. This is where we gave
> up on the design, at least for the time being. We currently implement
> only public voting with full disclosure of all relations:
>
>
> name voter ID 1 (maybe public key)
> \ /
> address -- rID ------------ voter ID 2
> / \
> electoral voter ID 3
> districts
>
>
> I sometimes wonder whether *any* privacy scheme for online voting
> would be solid enough in practice to warrant a promise to a vulnerable
> person: this is safe. Or even whether it's a worthwhile design goal.
> If it really is dangerous to express an opinion in public, then maybe
> we ought to work on eliminating that danger at its source, rather than
> dodging it with complicated workarounds.
Yes certainly "eliminating that danger at its source" is better, but
part of doing so may be voting for someone. It's not an either/or
decision. That it's perfectly safe may never be a promise, but it
would be good to be able to say that it's pretty safe, or at least
safer.
Travis
Travis
>
> Since I began working on this over a year ago, I've had these convos
> countless times with probably hundreds of people, and have discovered that
> similar convos have been happening for at least the past decade. We've
> generated a list of 30+ key issues that almost always come up when
> discussing the implications of a proxy voting system for mass scale
> governance. (Those will be listed on a wiki we're setting up soon.)
Naturally anonymization and democracy and the intersection of the two
has been discussed many times by many smart people. There may be
nothing new under the sun, but those old things can be obscure.
Please provide a URL to the wiki when it's up :)
Travis
Michael Allan
Douglas Rushkoff wrote:
> > ... If it really is dangerous to express an opinion in public,
> > then maybe we ought to work on eliminating that danger at its
> > source, rather than dodging it with complicated workarounds.
>
> It's "source" meaning the society of repression in which
> transparency is [vulnerable]?
I take it you mean structural elements that impede free expression?
Yes, I think it would be better to eliminate all such impediments
rather than to tiptoe around them. Better still would be to prevent
them in the first place, of course.
For instance, if the Dynamic Democracy Initiative were to succeed in
"raising money to employ a team of fulltime developers" for LayerVote
and Swayy (Micah), then it might have the unforseen consequence of
raising a structural impediment in the form of a monopoly. Much
depends on the nature of those investments, of course, but usually
investors are happy to see competing enterprises knocked out of the
field. We might not worry about being saddled with a Twitter or
Facebook as a consequence, but voting is no ordinary social medium.
Even a benevolent monopoly could undermine our chances for political
liberty in ways that the most poorly designed and tightly controlled
of micro-blogs or publicity networks never could. Don't you agree?
Travis wrote:
> I'm not imagining that updates are propagated at all. In fact, the
> vID should be discarded after every vote to minimize the collection
> of data around a vID. For example, timing of the submission of the
> vote and means of transmission (key fob, tor, etc).
I see. A possible problem is with continuous voting that runs 24x7.
The votes are shiftable and the process is potentially never ending.
The vID and its attached registration properties (such as electoral
districts) will become out of date.
> The weakness I see in the method I've described is selection of the
> group to submit public keys for. The group would need to be as big
> and diverse as possible, but small enough that everyone in the group
> knows for certain there is no pollution of the public keys
> submitted.
I understand the size problem, but not the pollution problem. The
system allows any user who authenticates as a registrant (rID) to
submit a vID to a nascent group (rID * n, vID * n) in formation. This
is just conventional user authentication, so no problem. The new pair
(rID, vID) can be accepted into the group as bona fide, and the system
immediately forgets the pair binding. That should work, or did I miss
something?
Micah Daigle wrote:
> *That's one reason [duplicative discussion] for hosting the Upgrade
> Democracy Summit: to bring a wide range of people together to
> discuss these topics and capture the outcomes in the wiki.*
>
> It's also important that members of this movement get to interact
> and build relationships with others who are working on similar
> projects.
I agree, but we're competitors. We're out to clobber each other.
We've had conferences and wikis in the past, so in what sense is this
non-duplicative? I'm very hopeful about the possibilities for some
minimal level of cooperation among the projects, but these old methods
do not sound promising. Or am I missing something?
--
Michael Allan
Toronto, +1 416-699-9528
http://zelea.com/
Douglas Rushkoff wrote:
> It's "source" meaning the society of repression in which
> transparency is vulnerability?
Travis wrote:
> Excerpts from Michael Allan's message of Fri Nov 25 06:30:35 -0700 2011:
> >
> > Travis wrote:
> > > Interesting! But why does the equivalence need to be kept at all?
> > > ... I'm envisioning a process where a bunch of citizens together
> > > generate key pairs using gpg. Of course they keep their private keys
> > > secret from each other, but in one transaction they submit their
> > > collection of public keys to a registrar. The registrar notes that
> > > all citizens in the list can not register another public key, but
> > > doesn't know which key belongs to who. Votes are then signed with
> > > the private key and submitted through some mechanism that avoids
> > > identification like onion routing, or putting thumb drives into a
> > > hat. ...
> >
> > So instead of a simple equivalence of registrant identifiers (1), you
> > essentially propose an equivalence of groups (2).
> >
> > (1) rID = vID
> >
> > (2) rID * n = vID * n
> >
> > where: rID is an ordinary registrant identifier, and
> > vID is a proxy identifier for private voting
>
> Sounds right. I appreciate your carefully laid out ASCII.
>
> >
> > The registrar knows that each rID in the left group is bound to a vID
> > in the right group, but does not know exactly which one; only the
> > registrant knows. This causes an interesting problem. To see it, we
> > must look at some details in the registry. Here are relations between
> > registration properties (left) and various formal identifiers:
> >
> >
> > Voter registry Vote-servers
> > ====================== ===============================
> > name voter ID 1 (maybe public key)
> > \ /
> > address -- rID -- vID ----- voter ID 2
> > / / \
> > electoral ---+ voter ID 3
> > districts
> >
> >
> > All of these relations are public except the proxy relation rID = vID.
> > This is kept hidden either by a proxy blind (secret of registrar and
> > registrant), or by group equivalance (registrant only). The problem
> > with the latter is that *some* registration properties (left) are
> > attached to both rID and vID. For instance, vote-servers must know
> > which electoral districts a given vID is entitled to vote in. Now
> > imagine a registrant (rID) updates his/her electoral districts. How
> > is this update propagated to the proxy vID when the relation rID = vID
> > is unknown to the system? Or if the registrant propagates it, then
> > who authenticates it?
>
> I'm not imagining that updates are propagated at all. In fact, the vID
> should be discarded after every vote to minimize the collection of
> data around a vID. For example, timing of the submission of the vote
> and means of transmission (key fob, tor, etc).
>
> The weakness I see in the method I've described is selection of the
> group to submit public keys for. The group would need to be as big and
> diverse as possible, but small enough that everyone in the group knows
> for certain there is no pollution of the public keys submitted.
>
>
> >
> > BTW, this propagation of updates is one of the weaknesses of the proxy
> > blind design. Detection of identical updates between an rID and vID
> > could reveal the secret relation between them. This is where we gave
> > up on the design, at least for the time being. We currently implement
> > only public voting with full disclosure of all relations:
> >
> >
> > name voter ID 1 (maybe public key)
> > \ /
> > address -- rID ------------ voter ID 2
> > / \
> > electoral voter ID 3
> > districts
> >
> >
> > I sometimes wonder whether *any* privacy scheme for online voting
> > would be solid enough in practice to warrant a promise to a vulnerable
> > person: this is safe. Or even whether it's a worthwhile design goal.
> > If it really is dangerous to express an opinion in public, then maybe
> > we ought to work on eliminating that danger at its source, rather than
> > dodging it with complicated workarounds.
>
> Yes certainly "eliminating that danger at its source" is better, but
> part of doing so may be voting for someone. It's not an either/or
> decision. That it's perfectly safe may never be a promise, but it
> would be good to be able to say that it's pretty safe, or at least
> safer.
>
> Travis
Micah Daigle wrote:
> Hi all,
>
> Apologies for the delayed reply here... my inbox has been marking these as
> spam for some reason, so I just found the thread.
>
> A few things....
>
> 1.
>
> To clarify, *"Upgrade Democracy" and "The Dynamic Democracy Initiative" are
> two different, overlapping entities* (they coexist on the same website
> right now, but we are splitting them ASAP).
>
> The former is a broad term we're using to describe the movement of folks
> working to, well, upgrade democracy.
>
> The latter is the organization I founded about a year ago to begin working
> on some specific technology and also help create the space for external
> innovation to happen (hackathons, prizes, etc). It's just beginning to 'go
> operational' now.
>
> If it helps, think about Upgrade Democracy like the "free culture
> movement<http://en.wikipedia.org/wiki/Free_culture_movement>"
> and DDI like the Wikimedia Foundation or Creative Commons. One is a loose
> association, while the other is an actual legal entity working on specific
> projects.
>
> 2.
>
> The working group at ContactCon was a loose collection of people who are
> working on (or interested in working on) upgrading democracy, most of whom
> were meeting for the first time. However, since several of us had been
> collaborating as members of DDI for many months before ContactCon, we took
> the lead of some of the conversations.
>
> So, *Keenan's notes were coming from his viewpoint*, and shouldn't be
> thought to represent the opinions / goals / etc of everyone who was in our
> working group, or of DDI. I think Keenan tried to make this clear when
> posting the notes, but it's worth reiterating.
>
> 3.
>
> As for the specific software being built, there's a project called
> LayerVote which is a basic proxy voting prototype, being developed by a few
> people in our spare time. However, this has been slow-going since it's a
> volunteer project, so *I'm currently raising money to employ a team of **
> fulltime **developers*.
>
> Our goal is to launch Swayy Beta within the next six months. Swayy aims to
> be the best software for discussing, debating, and deciding on anything,
> from public policy to what to name your business. The proxy voting concept
> we've been toying with in the context of LayerVote will be a "trust layer"
> in Swayy that will give people more sway in given topics.
>
> 4.
>
> I love the discussion happening on this thread, particularly around the
> specifics of how a next gen democracy would work (such as private voting vs
> public voting).
>
> It's also, unfortunately, duplicative.
>
> Since I began working on this over a year ago, I've had these convos
> countless times with probably hundreds of people, and have discovered that
> similar convos have been happening for at least the past decade. We've
> generated a list of 30+ key issues that almost always come up when
> discussing the implications of a proxy voting system for mass scale
> governance. (Those will be listed on a wiki we're setting up soon.)
>
> *That's one reason for hosting the Upgrade Democracy Summit: to bring a
> wide range of people together to discuss these topics and capture the
> outcomes in the wiki.*
Travis
I see. A possible problem is with continuous voting that runs 24x7.
The votes are shiftable and the process is potentially never ending.
The vID and its attached registration properties (such as electoral
districts) will become out of date.
If the process never ends is it voting? Isn't coming to a decision
within a reasonable time constraint a goal of voting systems? How
much would eligibility to vote really change in such a period of time?
I understand the size problem, but not the pollution problem. The
system allows any user who authenticates as a registrant (rID) to
submit a vID to a nascent group (rID * n, vID * n) in formation. This
is just conventional user authentication, so no problem. The new pair
(rID, vID) can be accepted into the group as bona fide, and the system
immediately forgets the pair binding. That should work, or did I miss
something?
I'm defining "pollution" as where someone registers someone
else's public key as theirs. It could be a sale or a coercion. Having
the rID -> vID map be vetted by a group smaller than, say, Dunbar's
number seems like the way to combat pollution.
Alternatively, pollution could be considered out of scope in which
case the vID set simply needs to be confirmed with each rID holder
that their respective vID is in there. This could be done with a very
big set of people, which would be ideal for individual anonymity.
This confirmation needs to be done because the voting system
only knows about vIDs and can't inspect the rID -> vID process.
If it could, then it could accidentally or purposefully retain the
mapping, or delete the mapping in a way that is recoverable.
So for tl;dr purposes:
There need to be two completely separate systems. A manages
anonymization of registered voters and has no idea how such
registrants actually vote. B manages votes anonymously and
has no idea who is voting, only that they are registered. When
that registration needs an update, B needs to utilize A.
To me, using software that doesn't keep logs, or anonymizes data,
is not good enough. That's just making promises that could be
broken by a corrupt system in which the software is used.
Travis
Hellekin O. Wolf
> Dear Hellekin,
>
>
>> ... I think a private vote is *necessary*
>>
> because the citizens are too frightened to voice their opinions in
> public. But I think this situation is itself incompatible with any
> substansive democracy or political freedom.
>
'tabula rasa': there's a pre-existing situation, and you have to adapt
to it. It's not as simple as 'citizens are too frightened': in Egypt,
Syria, Lybia, etc. they're frightened, and for good reason, but they go
beyond their fears and face death to change their societies. You just
cannot take freedom of speech for granted. And then, you have other
issues, such as manipulation of opinion.
> We citizens are capable of
> safeguarding our own freedoms of speech and political participation by
> our own efforts, provided only that we have an unrestricted choice of
> the underlying media. *
>
>
*** And provided that you have freedom of speech, and no death squadrons
around to keep you in line.
>
> I'm not sure I understand this kind of "intimacy", or how it bears on
> public voting. Can you provide a specific example where a public vote
> has harmful effects in this regard?
>
>
*** You work for a big corporation. For the money, for the doors it
opens to you when you need it. But you really don't like their policy
on X, a public matter. On Sunday, you vote against X. On Monday,
you're fired.
> * Upgrade Democracy is discussed in this forum (invite only):
> http://www.facebook.com/groups/upgradedemocracy/
>
> Who are the members of the coalition, does anyone know?
>
*** I don't have a Facebook account.
Cheers,
==
hk
Michael Allan
Travis wrote:
> If the process never ends is it voting? Isn't coming to a decision
> within a reasonable time constraint a goal of voting systems? How
> much would eligibility to vote really change in such a period of
> time?
I guess there are different kinds of voting for different purposes.
One purpose is snap decisions, and there it's OK to have time limits
and cut-offs. Another purpose is discussion aimed at general
agreement or mutual understanding, and here I think the process cannot
be rushed or forced. It might take years for people to reach an
agreement on the content of some draft legislation, or decades - or it
might never be reached. But there will always be a need for mutual
understanding along the way (what differences do we have in society?
why are we unable to agree?), which in turn requires a process of
continuous voting, drafting and discussion.
Hellekin wrote:
> > ... We citizens are capable of safeguarding our own freedoms of
> > speech and political participation by our own efforts, provided
> > only that we have an unrestricted choice of the underlying
> > media.
>
> *** And provided that you have freedom of speech, and no death
> squadrons around to keep you in line.
Yes, though I only meant to speak there of safeguards of a freedom
*already* possessed. So we'd be gaurding against its loss or erosion.
(But to the extent we're terrorized by thugs, we have no freedom to
begin with.)
> *** You work for a big corporation. For the money, for the doors it
> opens to you when you need it. But you really don't like their
> policy on X, a public matter. On Sunday, you vote against X. On
> Monday, you're fired.
Here an employer is denying an employee freedom of speech/belief in
off work hours. If that form of coercion is wrong (in most situations
it is), then we can detect it by statistical means and expose it to
public scrutiny. This would fall roughly under item (b):
http://zelea.com/project/votorola/d/theory.xht#vote-buy
Note that a wrongful practice that would otherwise go undetected is
here exposed through public voting. So this an example of how we can
safeguard freedom by our own efforts.
--
Michael Allan
Toronto, +1 416-699-9528
http://zelea.com/
Hellekin O. Wolf
> Dear Travis and Hellekin,
>
> Travis wrote:
>
>> If the process never ends is it voting? Isn't coming to a decision
>> within a reasonable time constraint a goal of voting systems? How
>> much would eligibility to vote really change in such a period of
>> time?
>>
> I guess there are different kinds of voting for different purposes.
> One purpose is snap decisions, and there it's OK to have time limits
> and cut-offs. Another purpose is discussion aimed at general
> agreement or mutual understanding, and here I think the process cannot
> be rushed or forced. It might take years for people to reach an
> agreement on the content of some draft legislation, or decades - or it
> might never be reached. But there will always be a need for mutual
> understanding along the way (what differences do we have in society?
> why are we unable to agree?), which in turn requires a process of
> continuous voting, drafting and discussion.
>
a cheesy replacement for "building consensus". I see democracy as a
conversation. Sometimes, it becomes focused discussion, when you need
things to be done. But more generally, it's just a flow of
self-reflective minds interlacing and weaving their reflections, to
mirror something common, between and beyond them(us). Time of course,
is an important part of the process. But guess what: we let the process
go free-rolling for 150 years or so. Now we're about to hit a wall, big
time, at full speed. I don't expect us to have much time, nor the
inclination (wink) to come up with a world in which people spend their
time voting on issues. Or maybe I'm wrong, and people will enjoy voting
with a remote control, "exercizing their democratic power at the tip of
a thumb", debating here, trusting there, until the accumulation of
things to do becomes the things done... Until tomorrow comes with more
questions to audit, more thumbs to tap, more trust to give...
Participatory politics require participation, and participation requires
time. The time you take voting, you don't take doing. How much voting
is good for democracy? Should we learn to better communicate and
understand each other, voting would quickly become an exceptional thing
to do. Voting is not so much important as to getting things done.
Corporations don't vote before taking over the world: they do it.
> Hellekin wrote:
>
>>> ... We citizens are capable of safeguarding our own freedoms of
>>> speech and political participation by our own efforts, provided
>>> only that we have an unrestricted choice of the underlying
>>> media.
>>>
>> *** And provided that you have freedom of speech, and no death
>> squadrons around to keep you in line.
>>
> Yes, though I only meant to speak there of safeguards of a freedom
> *already* possessed. So we'd be gaurding against its loss or erosion.
> (But to the extent we're terrorized by thugs, we have no freedom to
> begin with.)
>
*** You don't need thugs. You need massive noise to drown the signal to
noise level. Mass-media (as mass murder)
>> *** You work for a big corporation. For the money, for the doors it
>> opens to you when you need it. But you really don't like their
>> policy on X, a public matter. On Sunday, you vote against X. On
>> Monday, you're fired.
>>
> Here an employer is denying an employee freedom of speech/belief in
> off work hours.
*** Say you're a journalist, you work on Sundays. Say you work for a
big newspaper, covering a social movement. Say you hold a funny sign
for a minute, you're photographed, and your portrait goes around the
world and becomes instantly famous. That *would* not happen: that *did*
happen. We're not talking about theory here, buddy. It's XXIst Century
fucking US of A. Wake up! Erosion of freedom has already turned it into
a nice warm sandy beach: it's all flat out there.
I like Avaaz.org. It's like voting for real. But in what they're
doing, voting is not really the important part of it. Deciding to do
it, and doing it is the thing. Stepping up from would to could, and
convince people that with the numbers, yes, we can. Of course, the
"can" has to be "free". Otherwise, it's like the moo-box: you turn it
upside down and the cow moos. No side effect. But if it's free, as in
Free Speech, and CAN, as in hell yeah! Let's do it now, then yes, the
symbolic institution of embedding consensus into action takes back its
meaning: to make sense.
That's the only thing I care about. Voting, its ways and means, etc.,
are simply whistle blows in a storm. Turning ideas into facts, hell yeah!
==
hk