StirmeSpecsDraft: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
m (Reverted edits by My password is 22 (Talk) to last revision by Nolambar)
 
(5 intermediate revisions by 3 users not shown)
Line 21: Line 21:
== Design ==
== Design ==


As recommended by the OLPC, this software will be developed using Python and GKT. Also is intended that the graphical interface should be intuitive to any child.
As recommended by the OLPC, this software will be developed using Python and GTK. Also is intended that the graphical interface should be intuitive to any child.


Each laptop can be viewed as a node for the Stirme-network. Stirme will consist in two part, the clients or voting-booths and the server or voting-centre. Both parts will be implemented in the same bundle, so each node can act as a boot and as a centre.
Each laptop can be viewed as a node for the Stirme-network. Stirme will consist in two parts, the clients or voting-booths and the server or voting-centre. Both parts will be implemented in the same bundle, so each node can act as a booth and as a centre.


When Pepe decides to create an election, he can use his own voting-centre in his laptop with the stirme-activity or he can use a external voting-centre in a public server available. He will be asked for a title, description, the choices and an expiration date for the election he's creating. [write about owner signing]
When Pepe decides to create an election, he can use his own voting-centre in his laptop with the stirme-activity or he can use a external voting-centre in a public server available. He will be asked for a title, description, the choices and an expiration date for the election he's creating. [write about owner signing]


The voters would be faced to choose an election available to them, or enter manually a remote url where the election is being hosted. After that an interface will be displayed were they actually cast they casts their votes. This interface should be designed for every method of elections (Condorcet, Range Vote, etc). Before the vote is actually casted, the system must sign the vote with a digital sign identifying the voter.
The voters would be faced to choose an election available to them, or enter manually a remote url where the election is being hosted. After that an interface will be displayed were they actually cast their votes. This interface should be designed individually for every method of election (Condorcet, Range Vote, etc). Before the vote is actually casted, the system must sign the vote with a digital sign identifying the voter.


After the expiration date, the server calculates the outcome of the election using the method selected by the owner. This outcome then is signed by the owner and published.
After the expiration date, the server calculates the outcome of the election using the method selected by the owner. This outcome then is signed by the owner and published.


Each voter can request the whole election ballots and perform an independent recount of them assuring that his vote was counted.
Each voter can request the whole election ballots and perform an independent recount of them assuring that his vote was counted.



== Communication ==
== Communication ==


For now, the communication between the nodes will be handled with XML-RCP if no better alternative, inside sugar environment, is devised.
For now, the communication between the nodes will be handled with XML-RPC to make it more portable.



== Storage ==
== Storage ==
Line 49: Line 47:


=== GPG Keys ===
=== GPG Keys ===

We will wait until the team working on implementing RSA or DSA key finish, so we'll not duplicate efforts doing a "private" implamentation.

For now, we'll be using the JID or some kind of unique identifier available.

Latest revision as of 01:06, 11 December 2010

  english | 한국어 HowTo [ID# 249868]  +/-  


Discussion and draft of the Stirme Specification for OLPC

Summary

Stirme is about to provide the means for an instant electronic vote that is trustable, representative and is not dependant on a central authority. Any node can serve both as a voting centre or as a voting booth. This software should be extremely easy to use so that we could target the OLPC project (but not exclusively). It could then be used as a mean of teaching about democracy as well as an actual tool that will allow any community, whether it be local (classrooms, schools) or virtual (ONGs, open source projects) to participate in any decision process.

Use Cases

Representativity
Pepe and a few friends see some problems with the current school system. They create an election in an independent voting centre on a public server for their schoolmates where they can propose and decide in a representative way about actions they can take.
Consensus
Andrea's class breaks into an argument about how to approach a school project. They don't seem to be reaching an agreement, so Andrea quickly sets up a vote on her laptop and invites everyone to decide in a representative way.
Democratization
An open source community grows and its leader wants to open up the project for a more democratic representation. He provides the software for download on the project's page and invites the community to vote for a constitution on the project's online voting centre.
Decision
An NGO wants volunteers around the world to decide quickly on certain course of action and it provides an online voting centre for volunteers to subscribe to.

Design

As recommended by the OLPC, this software will be developed using Python and GTK. Also is intended that the graphical interface should be intuitive to any child.

Each laptop can be viewed as a node for the Stirme-network. Stirme will consist in two parts, the clients or voting-booths and the server or voting-centre. Both parts will be implemented in the same bundle, so each node can act as a booth and as a centre.

When Pepe decides to create an election, he can use his own voting-centre in his laptop with the stirme-activity or he can use a external voting-centre in a public server available. He will be asked for a title, description, the choices and an expiration date for the election he's creating. [write about owner signing]

The voters would be faced to choose an election available to them, or enter manually a remote url where the election is being hosted. After that an interface will be displayed were they actually cast their votes. This interface should be designed individually for every method of election (Condorcet, Range Vote, etc). Before the vote is actually casted, the system must sign the vote with a digital sign identifying the voter.

After the expiration date, the server calculates the outcome of the election using the method selected by the owner. This outcome then is signed by the owner and published.

Each voter can request the whole election ballots and perform an independent recount of them assuring that his vote was counted.

Communication

For now, the communication between the nodes will be handled with XML-RPC to make it more portable.

Storage

At first, the data will be saved within the voting-centre using sqlite.


Ballots

GPG Keys

We will wait until the team working on implementing RSA or DSA key finish, so we'll not duplicate efforts doing a "private" implamentation.

For now, we'll be using the JID or some kind of unique identifier available.