Polly/High Level Requirements

Some more meta-considerations about requirements follow, in no particular order.

Goal: "Foster participative democracy"

Representative democracy suffers from obvious problems where power gathers around an elite few, in turn attracting corruption. Historically this has had to be countered by endless manual "checks and balances" which led to the grossly inefficient governments we see before us, while the alternative participatory democratic processes have always been limited in scope because of the overheads of operating them in anything other than a small scale. The difference today is ubiquitous computing and networking, meaning that we can attempt to address the scale limitations that previously prevented large scale participative democracy.

Some Guiding Principles

Principle: "The Medium is the Message"

This is a very important concept when considering the design of an e-democracy system like this.

From Wikipedia:

"The medium is the message" is a phrase coined by Marshall McLuhan meaning that the form of a medium embeds itself in the message, creating a symbiotic relationship by which the medium influences how the message is perceived.

The structure of our design strongly influences the human communication it facilitates. The principles we want in our community must be stitched right into the structure of our design. These principles are not just loose abstractions; they should be understood, agreed on and then directly influence every design decision.

Principle: "Transparency"

Given that we're running on a platform of "Government Transparency", it seems only reasonable that we should "eat our own dog food". An example of this might be that there should be deep visibility through the system into how a decision has been made, where the contributions came from and even who voted, in which direction and how proxies are distributed.

Principle: "Visibility"

Transparent, yet visible! This actually makes as odd kind of sense. While "transparency" is about being able to see through the systems to the content inside, "visibility" is about the content of the systems being visible and apparent for all to see.

A specific case of this, is that the Google view of a the system should be that it sees Polly as the hub of discussion for Pirate Party issues, so that Google users queries lead them to us.

Principle: The System should be as "Simple as possible, but not simpler" (Einstein)

Nobody should need to read a manual or help text to use the system – at every step it should be obvious what you can do.

Principle: "Commensurate Returns"

People's first experience of the system should be that they get a lot of value for almost no exertion on their part. An example of this would be a completely new user without any credentials yet (so not even a member) being able to simply browse the discussions and decisions and see the process in action, even if they can't participate actively (assuming we agree with Transparency principle). This positions them in an emotionally more open position where it feels like its only a small step to sign-up and join in the activities.

Principle: "Provenance"

It should always be known where a decision came from and the factors than influenced it. It would be even nicer to know if decisions could be triggered for review, when those factors change, but that could be quite hard to do.

Some more focused principles and associated concepts

Principle: getting stuff done

It's all very well making collective decisions, but to be effective, we have to actually get stuff done.

Concept: all propositions are about actions

The system may support many different decision making templates, but there should be a few things in common between them:

1. They must clearly define the action to be taken.
2. They must have designated people who accept their role in the action.
   1. Some actions may be simple and only involve an existing party officer. e.g. Publish this new policy we agreed on.
   2. Some actions may require a large and distributed number of people.
      1. In this case, the decision action template would need to have sufficient people pledging to act, for the decision to pass.
3. In no case should a collective decision be used to attempt to force someone to act against their will.
   1. The designated person or persons must agree to the action for the initiative to pass.
   2. ISSUE: This rule could potentially be abused by party officials to veto anything they don't personally like.

Principle: Self Evident Integrity

Along with Transparency and Provenance comes the possibility of "Self Evident Integrity". Security/authentication is never perfect and there will be incentives to cheat. It should be evident to the originator of an account, when it has been in use.

• e.g. Email summaries of activity
• e.g. A history of activity should always be available.

Concept: Retention - Just do it.

• Nobody may edit, rewrite or delete history. Nothing gets thrown away. Ever.
• The point is that history must remain objective.

Principle: Engage with "The Long Tail"

In any system where a large number of people can contribute, there will be an L-Curve style or "Pareto" distribution where a small number of people provide very large contributions and a large number of people provide very small contributions (the long tail of small contributors). It is important that the system actively engage the long tail of small contributors because:

• They are its greatest source of diversity, ensuring inclusiveness and wide acceptance.
• They are the source of future large contributors (refer "Commensurate returns" principle), ensuring its future.

Concept: Anonymity (Minor issue; refer to Pseudonymity)

Passive (read-only) participants could be truly anonymous, though we might like to count how much of this goes on and report on it. I don't think active participants can be truly anonymous or else it would violate the integrity of voting systems.

Concept: Pseudonymity

There are many potential merits in allowing pseudonymity. A user would necessarily have a single unique identity known to the system which would only have a single unit of voting power, but there may be utility in allowing that user to appear in different parts of the system as one of potentially many different pseudonyms. Pseudonymity may protect the real-world identity of an individual who simply wants their ideas to be considered on their merit, but does not want their employers to know their opinions or to receive real-world unpleasantness like stalkers or similar threats. Pseudonymity may be of particular relevence to very well known members who wanted to participate in groups/forums that are not currently central to their expertise where they don't want their early uninformed thought to unduely influence discussion. Pseudonymity allows more memorable or descriptive names that may more obviously relate to a particular expertise, position or intent.

Concept: Structured Discussion

Fully constructed, ready-to-vote proposals do not just appear spontaneously. The system needs to support the eventual emergence of ready-to-vote proposals from widely spread loosely structured discussion. I think a potentially less formal implementation of the Voting (concept below) should apply in Structured Discussion to allow the most significantly expressed concerns to bubble up to the forefront of discussion. Take a look at the way this emergence happens in Reddit.com as an example of this concept in action.

Concept: Discussion Space

The most basic unit of discussion would be like an EtherPad. Just text plus simple formatting many people can type in it concurrently. Discussions can ensue, along with voting (see below). Optionally, we could spin off IRC chats (with full history), voice conferences or similar to help it along. We could probably use embedded EtherPad pages, but with some voting and other controls at the top. They could just be opened in a new tab on your browser, so you had lots of space to type and view and can have many open concurrently.

Principle: Top Down and Bottom Up Concurrently

When trying to solve problems in complex systems, best practice is not top down or bottom up design. It is both concurrently. This applies to software development and it applies to the design of social systems also. Blindly attempting to apply ideologies is dangerous and trying to micromanage the world is hopelessly inefficient. If we have guiding principles (or loose ideologies) and we ground them in the real world nitty gritty situations where they will be applied, then we can refine our principles and develop effective strategies for their application. Further, decomposing massive problems into large problems and large problems into smaller problems, lets us handle problems in bite sized chunks. This system should directly encourage and support this sort of behavior.

Concept: Hierarchy of Discussion Spaces

In support of "Principle: Top Down and Bottom Up Concurrently", issues under discussion may be formed into a hierarchy. Issue -> (SubIssue1 -> (SubSubIssue1, SubSubIssue2), SubIssue2) etc.

It is entirely up to the people involved how they decide to break issues down. Ordering of Issues/Sub-Issues at the same level should be based on member vote.

Concept: "People who voted for this also voted for that"

In the interests of engaging a wider grass roots level engagement, people need a way to know which discussions and votes are happening that they would likely have an interest in.

The regular email reports should include reports on:

• Areas/issues of interest, matching key words, that you have not voted on.
• Areas/issues being voted on by people that also voted on other issues you have voted on in the past.

Principle: Keep a Lid on the Crazy

Any large collection of people is going to include a certain percentage of people with beliefs that are in the outlying areas of a normal distribution. As a general principle, I don't think we want to actively exclude these people from discussions. They may actually be partially or fully right. Diversity is good. What we do want to do is to ensure that there is a high enough barrier of rational discourse between their beliefs and party policy or actions, that we are reasonably certain only the good stuff gets through.

Concept: Multi-Attribute Utility Theory (MAUT)

Attempting to achieve consensus amongst a large group can be difficult using raw discussion alone. People may become entrenched in unproductive emotive oppositional dialog. We don't want people to lose their passion for the issues that concern them, but we do want to ensure that their passion is based upon an objectively correct interpretation of each others positions. There are some well established tools and processes that we could build in to help with this. Here is a detailed technical explanation of MAUT: http://wiki.ece.cmu.edu/ddl/index.php/Multiattribute_utility_theory

Here is my own simple conceptual model for understanding this:

• Draw a grid of Criteria (down the left) .vs. Proposed Options (across the top).
• Collaboratively:
  • People add/update/delete Criteria and Proposed Options amongst rampant discussion until everyone is satisfied that the Proposed Options are representative of the actual ideas and the Criteria are as discreet as possible and representative of peoples actual concerns.
• Individually:
  • Give each criterion a weighting value.
    • All criteria start off with a fixed weight value (e.g. 10)
    • Weights may be locked-in.
    • Increasing the weight of one criterion decreases the remaining non-locked-in criteria.
  • In each square, chooses a number between 1 and 10 (with description e.g. "10 - Awesome") to represent how well each choice rates against the criterion.
• The System:
  • Multiplies Criteria by Proposal score in each square. Sums columns.
  • Contrasts your personal result against the collective result.
    • Shows some measure of disparity to highlight the need for further discussion.
  • Allows a period of iteration and adjustment.

Having reviewed some of the outcomes of the German PP LQFB system, I think this feature is a mandatory inclusion.

Concept: Evidence as Comprehensive Descriptions + Citations

A desirable goal is for evidence based decision making. As decision tables such as MAUT (described above) are created, we need the individual criteria and proposals to be as supported by evidence as reasonably possible.

There is a long tradition in the academic world, of citations. Some citations are considered more authoritative than others. The PPAU has a citation guide that we use as a basis for referencing materials relevant to a policy decision https://pirateparty.org.au/wiki/Citation_Guide

While it is desirable for layout purposes to keep decision tables brief and to-the-point on-screen, the surrounding documentation linked from each criteria or proposal option should include a citations facility.

Principle: Polly Abides

Polly should assist its users to abide by the rules that govern us. Rules built in to or configured within Polly must reflect the constitution of the PPAU. Polly should never be used to or assist people to violate the laws of the land.

Concept: Moderators

There need to be some rules of engagement and somebody has to be able to enforce them. "Moderators" are those somebodies and should be elected and able to be unelected by the community. Moderators should get a second system identity, independent of their regular user. Their moderator identity would have no voting rights(so they don't get two votes), but would have special moderator powers. Creating/deleting moderator users should only be able to happen as a consequence of a voted activity, not as a system power assigned to someone.

Concept: Acceptable Conduct - The "Pirate Code"

Acceptable Conduct can most likely be based on mutually agreed community standards and may change over time and be different in different levels of engagement. Rules of engagement should be clearly stated and accessible. No trolling, generally civil discourse, no advocating violence etc. Enforcement should be visible to all, proportional to the transgression and progressive in nature so as to never come as a surprise.

Concept: Moderator Discussion Tagging

Whilst it is not the role of a moderator to attempt to influence voting, they are charged with the responsibility of ensuring that proper procedure is followed. Generally wherever possible, Polly will be constructed to directly impose 'proper procedure'. e.g If the PPAU Constitution specifies a voting quorum and pass criteria, then Polly could directly enforce those. However, where enforcement of the conditions involves an actual understanding of member proposals and comparing them to PPAU constitutions and other rules, it will be down to the moderators to make an initial judgement on the topic. Further to this however, Polly should be designed to allow that this moderation process happens more like assistance and guiding rather than anything adversarial. At the level of early discussion, a good example to follow might be the way that Wikipedia moderators tag articles with one or more pre-established criteria to describe how it is failing to meet guidelines. The members engaged in trying to raise their proposal from the level of discussion through to a formally vote-ready proposition would need to adjust proposals to bring it back in to line before it could proceed to vote.

Concept: Moderate to manage financial consequences of collective decisions

Many individuals or small groups, each optimizing their own outcomes may collectively destroy common resources to the detriment of all. In the context of Polly and the Pirate Party, the common resources are the assets, funds, reputation and good will of the party. There needs to be a constitutional basis for restricting things like overspending. Any passed proposition that requires party funds would need to result in a request to the NC. Self funding propositions would not need this.

Concept: Resolving Disagreement with Moderators

If a member engaged in the creation of proposals through Polly disagrees with a moderators assessment of these rules, they may refer the issue to the PPAU Dispute Resolution Council. This is in compliance with the Interpretation clause of the Article 7 of the PPAU Constitution:

 Where a dispute may arise with regards to the interpretation of this constitution, 
 the Dispute Resolution Committee shall in accordance with Article 10 make a determination
 with regards to the dispute.

Principle: All Votes are Equal

Each person gets only a single unit of voting power.

Concept: Voting on Issues in Discussions

Each person may apply their single unit of voting power to any issue they like and to as many issues as they like. They may not apply their single unit of voting power to the same issue twice. Voting a second time on the same issue will simply replace your previous vote with your new vote. As per "Hierarchy of Discussion Spaces", issues may have many levels. Each persons may vote at as many different levels of a discussion as they see fit. This does not violate the single vote principle because sub-issues are also issues. When agreement can not be achieved in a high level issue, people should be encouraged to break the issue down into sub-issues and vote on those to discover the source of their disagreement (refer Principle: Top Down and Bottom Up Concurrently). This may take the form of moderator tagging(e.g. "Breakout Recommended"). See how this is done in Wikipedia.

Principle: To each his own

We should not expect all people to be able to weight-in on all issues all of the time. People all have their areas of interest, expertise and passion. We can best leverage the people involved if they are able to focus on their own preferred areas. We can support this efficiency by allowing delegation of votes.

Concept: Delegation of Votes

The delegation of a vote applies to a person in a specified area of interest. I may for example, delegate my vote on matters of copyright law reform, to an acknowledged expert in that field. The effect is that the delegatee now wields the power of an additional vote in that field. Delegated votes may also be further delegated, thereby forming networks of trust.

Concept: Delegation Reporting

You should know what is happening in your name. The delegator of a vote will be notified of all use of that delegated vote in regular emailed report, along with the report of their own activity.

Concept: Revocation of Delegation

Delegation may be taken back as easily as it was given, so the delegatee is incented to continue with the behavior that earned trust originally.

Concept: Retrospective Delegation

If A delegates to B for issue C, but B has already voted on C, does A's vote automatically strengthen B's existing vote? My perspective is that this should be the default behavior of the delegation system - AndrewD

Concept: Delegation Override

If A delegates to B for issue C and subsequently votes themselves on issue C or a sub-issue thereof, this will override the originally delegated vote.

Allowing a delegator to generally roll with their delegatee in the specified area of interest, but to also override votes where they disagree will provide a more subtle feedback mechanism for delegatees than the more absolute revocation of delegation.

Furthermore, for where votes are for binding decisions, there should be a specified cooling-off period after the initial voting period, where only delegation-overrides are allowed. This will help to prevent the abuse of delegated votes whereby a last minute and highly delegated vote is put in place against the expectations of the delegators.

Concept: Stagnant Delegation

If A delegates to B for issue C, but B is not voting on issue C, then A needs to know about this. Their vote is being wasted.

The periodic email reports on vote usage should indicate when a delegated vote is not being applied to the target issues.

Concept: Meta-Delegation ???

A delegates to B, the right to delegate A's vote (or delegated votes) within a specified domain. This may tend to facilitate factions, but rapid revocation would still apply and as always, your nightly email would still show what is happening with your vote. Probably a future facility. Not high on the priority list.

Concept: Split-Delegation ???

Within a specified domain, A delegates a fraction of their delegate-able votes to B. This could be a useful concept in allowing someone with many delegated votes to balance out the power base on an issue to force wider participation for the motion to pass. Probably a future facility. Not high on the priority list.

Principle: Reputation should precede Authority

Delegation is the means by which Authority is accumulated in this system. In a small group, it is easy to figure out who to delegate your votes to on each issue. You just listen to what each person in the group says or review their history of actions in the area of concern and then you choose. However, in a large group (100's or 1000's of people), people need a basis on which to filter the potential recipients of their delegated votes. They will not have the time to review the track record of everyone involved. The usual human response in this situation is to simply "ask around" - "Who's the goto guy in this space?". Reflecting this model in to the context of Polly, we end up needing a Reputation System. Further to this, I think that the historically mediums of political discourse have led to a situation where authority tends to accrete around the largest personalities rather than the most qualified. However, in practise, people who are most qualified to comment in an area are often more conservative in the expression of their opinions because they know the complexities and do not want to present simplistic answers. So, the squeaky wheel analogy should not apply here. Judgement should be based on a track record of effective behaviour, not immediate image and bluster.

Concept: Reputation System

Conveniently, Delegation is a reflection of extant Reputation. However, reputation is not static. When we try to understand reputations, we need to know:

• Trends over time. Is a reputation growing or declining? Any sudden changes? How volatile is it?
  • This is quite objective information that we can produce statistically, based on a persons delegation history.
• What is their voting history?
  • This is quite objective information that we can simply list by issue.
• Why is each persons reputation the way it is?
  • This is more subjective information, that we may collect by allowing comments as a part of the delegation process.
  • See also "Motivation through Recognition" below.
• Reputation in a Fixed Pool
  • Reputation operates in a closed system. There is only so much to go around.
  • The pool of available repute scales in relation to the number of users.
  • Users actual reputation score, is then their relative repute within the global repute space.
• Reputation Aging
  • As duration since the deeds for which a user acquired repute increases, the affect diminishes linearly.
  • The rate of reputation aging will need to be tuned, but may best be tied to the rate at which new reputation is generated.
    • In this way, a very active populace will most rapidly age the reputation of the more inactive users.

Principle: Embracing the Newbs

Long term core party members already know each other well and they 'know the ropes'. For them, engaging with party activities is usually about finding enough time in the day to do all the things they would like to. It can be easy for them to misjudge the apparent apathy of newcomers. When you first join a new physical organization (like starting a new job), the stage is set; expectations are written down and people tell you what is expected. Joining PPAU is different.

• We're mostly online - so nobody sees you standing around wondering where the action is at.
• Participation is voluntary - so motivation is central.
• The hours of activity are sparsely spread - so serendipity needs to be engineered.

Concept: Newbie See, Newbie Do

Making peoples activities transparently logged will allow us to present an environment in which newcomers can see the sort of activities we want them to emulate.

Wherever a user name is seen, clicking it should lead you to a user page that (amongst other things) lists their PPAU Roles and recent activities.

Providing recognition of activities and their contribution gives the clues about what sort of activities are preferred.

To understand the significance of the activities and contributions, you need to understand something of the reputation of the people performing these activities. It should be possible to see the voting history (where public), reputation, areas and degree of delegation and official positions held of any user. Some of this may more simply be made visible by means of the rendering of their name (or pseudonym). For example, party officials might be in red, people holding delegations might be in bold, people may be listed reverse order of their number of delegations or simply have their number of delegations printed after their name "VoterName(42)".

Concept: Motivation through Recognition

Allowing people to +1 activities they approve of provides a way to show recognition despite the online sparsity. Maybe there's a scale of +1 that relates to the level of recognition of the person doing the +1. The point is to create a positive feedback loop around good activities and contribution. This also provides an intermediate step along the path towards having people delegate votes to someone. If you contribute a lot in an area and become recognized for your work, then people may start to delegate votes to you in that area.

Principle: Don't Screw Minorities

One of the potential pitfalls of fully participative democracy, is that a majority may severely mess with the interests of a minority. There's a couple of ways to look at this:

1. Assume most people are basically good and therefore won't do that.
2. Assume most people are rational enough to understand that on some issues, they too will be a minority. Karma will get you, so behave yourself.

In either case, the most important factor is that it needs to be obvious to all concerned when they are about to severely mess with the interests of a minority.

Concept: 2D Voting

The process of evolving an issue from a "loosely structured discussion" into a "ready-to-vote proposal" needs more than a Yes/No vote, but there still needs to be one person, one vote (and delegation).
In discussions, we don't actually need a single numeric representation of the result. Having one number doesn't matter.
What we do need, is an effective way for everyone to see how everyone is feeling about it.
Minorities caring deeply should stand out in this. So should a general consensus.

Here is one possible resolution of this:

• Voting is optional. Not voting expresses no interest or position on the matter and will not be counted in any way.
• If you do weigh in on an issue, there are two variables.
  • HowMuchICare (1 to 100, default=50)
  • HowMuchIAgree (-50 to 50, default=0)
• Your actual vote then is a position in the 2d coordinate space
• A useful derived concept is Concern = (HowMuchICare * abs(HowMuchIAgree)).
• Peoples preferred mode of comprehending this will vary, so present in multiple modalities concurrently:
  • Set using cross-hairs on a largish icon (perhaps scalable up to a larger chart)
  • Show numerical indication of HowMuchICare and HowMuchIAgree adjacent to the icon.
  • Show written description of below the icon. e.g. "I care deeply, I strongly disagree"
  • Show color indication of vote so it stands out. e.g. HowMuchICare (Dark->Light), HowMuchIAgree (Green->Red)
• Contrast this to the collective vote:
  • Showing vote distribution in the coordinate space.
  • Delegated votes should look like larger dots (area == count of delegated votes).
  • The degree of disparity should be obvious.
• This will be known as "2D Voting"

Principle: Transparency must trump Collusion

There is a fine line between cooperation/collaboration and "collusion". We call it "collusion" when it happens in secret. If people start forming voting blocks and secret deals through back-channels, the broader user population will lose faith in the system. The weakness of secret back-room deals for the participants in such deals, is that they rely on trust between people that are already behaving with dubious ethics and there is no public scrutiny of people who welch on deals. However, if there are no easy ways for people to make deals in-system, then I think people will revert to back-door methods. The solution then, it to make in-systems deals that are easy, transparent, honest and enforeable.

Concept: Build-in Deal Making

Example: If you vote up proposition A, I will vote up proposition B On both parties agreeing, the agreed votes will both be applied. If either side cancels the deal, both votes will automatically be removed. If one side manually overrides their vote, the other side will automatically be removed. Deals will be visible to all participants in any issue. No party will be able to enter into deals that conflict with any other deal they are already committed to.

Principle: People will Partition themselves into Decision Making Domains

1. People also have political and geographical boundaries that dictate separation of decision making. i.e. Countries, states etc.
2. As a separate issue, if everybody has to be heard on every decision that ever happens, the entire system will grind to a halt. This dictates the need for partitioning to support efficiency.

These seem like distinctly different cases of decision making partitioning.

Concept: Domain Partitioning

"Domain Partitioning" is the phrase I'm using to refer to case 1 above.
This is best handled by running independent instances of the Polly Application for each domain.
e.g. One for PPAU NSW, One for PPAU Federal etc.

Concept: Domain Import/Export of Issues

Domain partitioning further presents the need for the export/import of issues between Polly systems.
This would:

• Include: Issue descriptions and other documentation.
• Include: MAUT analysis (proposals .vs. criteria).
• Exclude: Actual votes.
• Exclude: Member information.

Mostly this facility would just provide for the spread and quick-start of popular positions between different domains.
However, it only provides a starting point. The target Polly system users need to review, tailor the issue to their locality and then vote.

Concept: Responsibility Partitioning

"Responsibility Partitioning" is the phrase I'm using to refer to case 2 above. I think this is about sub-groups that have been created by the party (probably by voting - another template needed), complete with people who are duly authorized to make decisions within a clearly specified domain or area of responsibility. This implies the need for a concept of Responsibility Groups, to which people may become members (by being voted in). Issues raised in this group should be visible to everybody (refer Principle of Transparency). Only the votes of people in the Responsibility Group will apply to decisions on these issues.
However, the broader community still needs a way to provide feedback into the groups if they find themselves disagreeing with the groups directions. I think non-binding voting plus comment ability should be sufficient to let the group know if the wider community has issues with them. Beyond that, if enough people are dissatisfied, they can raise a Vote of No-Confidence outside of the group to have it replaced or disbanded.

Principle: Factions will happen. Lets get them out in the open.

Some of the existing international Pirate Party organizations have been criticized for their inability to align due to factional infighting. Factions are a fact of life in political parties. Lets make them Transparent. Factions need not be an all-or-nothing thing. They typically divide along the lines of policy or broad issues segments. We already have the concept of delegation forwarding that could be used to form factions. Many people delegate their votes for an area of policy to a faction leader who in turn forwards those delegations to a set of faction representatives for each detailed area of interest in the faction. The problem with this is that simply looking at all of the individual delegations will not provide a clear understanding of factional divisions. However, I think that such visibility is vital for the health of the party, since it allows for respectful early facilitation of resolution between factional groups before they fall into entrenched oppositional positions.

Concept: Meta-Delegation

"Meta-Delegation" is the term I am adopting for delegation of delegation. I think we should be able to quite easily produce reports on the extent and structure of meta-delegation and make them visitble to anybody that cares to look.

Principle: The System must be Self Protecting

Entropy always wins in the end, but some structures are more resilient to its ravages than others. We need to design our system such that its natural tendency is towards maintaining its own integrity without extraordinary effort on the part of a few key people.

Concept: "Defence Against The Dark Arts" Considerations

Attack: "Direct Hack" - Defence = Preemtive and continuous replication of data. Distribution and fault tolerance. Just replace the physical infrastructure and the data replicates back.

Attack: Memetic Pollution - Defense = Open Networks of Trust One form of attack is to attempt to pollute the meme pool with propaganda, but propaganda only spreads when there is a lack of rational and trusted voices raised in opposition. Pseudonymity and Open Networks of Trust is our defense against propaganda because it creates the space for rational voices to be heard without persecution and to form networks of trust. In turn, the networks of trust stand in the way of the spread of malicious attacks on the meme pool.

Attack: Confidence Tricks - Defense = Rapid Revocation and Circles of Trust Once the propaganda proponents realize that their propaganda will not spread, their plan B will be to expend effort to gain a broad base of trust (at the lowest cost they can manage) and then once they have achieved that trust, to make use of it to more successfully inject the propaganda. The defense against this is called "Rapid Revocation" or "Screw me once and you are out of my circle of trust". Since circles of trust amongst a large population will naturally form what is called "Small World Networks" (remember the Kevin Bacon game?) - word rapidly gets around.

Attack: Memetic Corruption - Defense = Strong Authentication Another form of attack is to corrupt the memetic data. Just inject random data into the mix and watch it spread. The defense against this is Strong Authentication, to ensure that all data purported to have been added by a trusted identity really did come from that identity. Combine this with the Rapid Revocation and Circle of Trust concepts and corrupt data won't spread very far.

Attack: Identify Theft - Defense = Anonymity, Strong Authentication An attacker may try to fraudulently publish information against another individuals identity. The first line of defense against this is Strong Authentication, such that they can't do this without your permission. The second line of defense is Pseudonymity - If they don't know who you are, they can't lean on you personally. If you fail to protect your Pseudonymity or you have intentionally outed yourself, a truly aggressive attacker may attempt to force you under physical duress to put their message out under your identity, to either undermine you amongst your circles of trust or to leverage your circles of trust to insert more subtle misguidances. Frankly, I can't see this working - You'd just deny it all later or expose it anonymously later through another identity and have friends extends it their trust.

Principle: Collaboration

When participants log into Polly, it should be immediately apparent what activities are being conducted. While voting is important, there are numerous other activities which deserve attention, and one is the creation of documents. Any organisation will inevitably generate a great deal of written material. Examples of these include press releases and submission papers. As collaboration is a good way to ensure accuracy, consensus, transparency and quality, Polly should have a real-time collaborative text editor built into it. This would be a midpoint between EtherPad's simplicity and Google Docs' feature set. Documents should be tagged with and organised into various categories (e.g. "minutes," "press releases," "submissions") – Mozart.