This advisory concerns several proposals made to the Occupy* movement, suggesting processes & mechanisms for conducting online "General Assemblies" of sorts. The proposals we have reviewed mostly indicate use of Web tools in various ways to allow Internet users to submit - and usually vote on, with a familiar majority/supermajority mechanism - proposals in the GA format.
While we are very intensely interested in helping link distributed GAs for coordinated action: and we see that introducing Internet accessible supporters into the direct democratic / Occupy* decision-making process is an attractive goal: we are concerned that approaching this as an online forum, rather than a method of linking existing forums and processes, is tactically foolhardy and threatening to the direct democratic core of the movement. thus we wish to submit an alternative for the GAs' consideration that extends, rather than replacing, the consensus model & processes.
Instead of opening wider participatory space, we fear the pure online participation / [super]majority voting method to be fundamentally incompatible with establishing a CONSENSUS of the mutually committed in the established GA process: as well as an operational model highly susceptible to attack, untrustworthy / noise-filled, and difficult to implement at the scale it intrinsically requires.
We propose a sort of 'hybrid' alternative to this as GA supercoordination method: the SUPERASSEMBLY concept. We believe that by combining the localized, physical presence of the GAs with online tools & a tiny supercoordination team/process, this model can offer similar mass coordination benefits, but keep the current GA process, integrity of consensus & human accountability, better security, and possibly provide radical cost and bandwidth savings.
While this proposal does not solve the problem of building mass online mobilization, we think it is critical to attack these in parallel as separate problems. Attempting to solve both with the same stroke changes too many fundamental assumptions that have made the GAs so powerful and successful, and in a way places not just the operations but _the consensus_ needed for ground mobilization at risk of online attack.
The SUPERASSEMBLY we propose is not an online assembly of Internet users per se, but an method of creating linked physical assemblies which can handle common business using the exact GA processes they are already familiar with. No incongruous 'majority vote' mechanisms; no timed or random floors: the same stacking, facilitation-driven, CONSENSUS-seeking, human-centric forums we have now. Only bigger.
We do this by adding a _superfacilitation layer_ to each proceeding that uses the same process, gives participants the same level of soft & hard feedback into consensus; and gives even greater accountability to participants.
The central components of this approach:
(1) THE SUPERSTACK & SUPERFLOOR: the basic mechanism of the SUPERASSEMBLY is the "superstack" / "superfloor". Each GA in its normal operation manages several queues of speakers (stacks) and works with a moderator to allocate the current speaker (floor): so we think the simplest mechanism is apply the same system at a meta-level.
We simply add a SUPERSTACK which is a queue of each participating GA (each of which has its own queue of speakers), managed by superfacilitators collaborating actively with the GA facilitation teams: and allocate the superassembly's speakership via a SUPERFLOOR. This lets us use the same consensus checking, temperature interrupt, and blocking tools - as well as a team facilitation concept - at the largest possible assembly level. Same use cases: bigger field & different tools required.
We think this can be accomplished by tasking working groups of experienced facilitators and moderators of local GAs to coordinate on a per-assembly basis (with respective IWGs).
This simple extension of current process obviates situations like "needing 9/10ths majority to agree a simple majority vote" between Zuccotti Park & Washington Square, as we read in one notably comical tweet. Let's extend the model, not have to use the model to forcibly revise the model, if you catch our drift.
Figure 1: Operational Model: Superstacking & Facilitation
(2) AUDIO RELAY & FLOOR MGMT (THE PEOPLE'S PBX): The superassembly proceedings could be connected via a simple conferencing system that gets audio feeds relayed in each GA, and relays out the one that has the _superfloor_. This could be accomplished using a series of small, closed audio conferences, connected to local "RELAY" devices, which in turn feed the People's Mic. Again: extending the model that works, not throwing it out in favor of shinier tools.
Figure 2: Audio Relay / Switching System
Facilitators/moderators at each GA maintain at least two RELAY DEVICES on the ground, one relaying a feed in to the PPBX, one taking the current speaker feed out.
a) RELAY IN: remains connected to the conference persistently, and is always switched into the _superfloor_'s output. Someone holding that device simply stands in the audience and reads out the proceedings live: the People's Mic takes over from there.
b) RELAY OUT: used to read aloud from the People's Mic into the central PPBX, when on the "floor". The supermod monitors your output and the PPBX makes it available to the closed network of other GAs. When it is your GA's turn, this output is switched to the _superfloor_ and your relay out feeds other GA's relays in, as pictured here.
(3) THE SUPERFACILITATOR CHANNEL: a separate comms channel where facilitators at each site coordinate with the supermod/coord, covering critical operations like superstacking, floor switching, consensus reads, blocks and other interrupts, etc. We think this is optimally a visual medium like IM with no I/O ambiguity, non-interfering multichannel operation, and presenting no sensory competition with the audio channel.
Here is an example of a very simplified consensus check being conducted at the request of the superfacilitation team / mod, using direct communication with all the local GAs' ground facilitation teams. A chat room system is strongly implied here, but not the exclusive option.
Figure 3: Coordination Channel Call Flows For "Check Consensus" Scenario
Here is where the direct democratic rubber hits the proverbial road: here is how we preserve the consensus model across a large distributed group. We do not pretend that the volume and complexity of facilitating across this broad a group will be particularly easy, but we think very small procedural steps can mitigate this (hard/soft reportback times, etc.) and we are kidding ourselves collectively if we think that a mass movement will 'scale' in a raw efficiency sense while preserving its democratic principles. It will be messy: this way, it can be open and representative, at least.
We like this approach in part because the 'local loops' in this system can be powered by many different technologies, including some which are completely FLO and can be run with almost total independence.
(1) AUDIO CHANNELS (RELAY IN / OUT): for cost and quality reasons, we recommend using audio conferencing over standard mobile telephone service. This is mostly due to the signal optimization & noise cancellation HW uniquely available to this: streaming and "voice over IP" apps / services like Google Voice or Skype don't even have access to noise cancellation hardware on advanced mobile phones.
This also factors heavily into cost. Not only the raw cost-per-minute of broadcasting a quality, reliable stream to multiple receivers vs. cost of telephony based conferences (small ones are widely available for free at full quality); but the bandwidth cost, which taxes both the on-site power and Internet service. Optimized telephone system voice codecs conserve at least 50% - usually closer to 75% - over even voice-optimized "over the top" streaming, making more juice and air available to other Occupiers. And saving many, many $$$.
Finally, using telephony for the 'last mile' also opens up FLO software and totally independent operation options, such as deploying an independent telephony / PBX servers (thus the ideal 'people's PBX'. We greatly admire the work that Nathan Freitas (aks n8fr8) has done on Onestreetmic and think this could easily be repurposed to set up a trial local loop system for GA links.
2) COORDINATION/FACILITATION CHANNEL: an independent IRC channel can be had for free, using FLO software, or a reserved channel can be set up on a Web based system like Mebit. Commercial alternatives like Google Chat are also widely available as optimized client software for higher end devices.
In addition, an "operator channel" might be maintained, for example so that a technical coordinator can monitor relay quality & advise local coordinators to switch relay devices, move speaker, etc.
In brief, we believe the "Internet Assembly" approaches we have reviewed to date share the following fundamental challenges: to bet on it at this critical juncture would pose intolerable risks to the Occupy* movement's successes to date.
Even assuming a relatively secure online community & pure intent from participants (poor assumptions: see below), the simple majority vote mechanism embedded in the "national/regional assembly" proposals produces large scale COMPROMISE, not CONSENSUS.
A method that tries to drive issues to up & down votes rapidly forces not only compromise results, but leads participants into a binary engagement that doesn't proceed into a real facilitation process. It asks the question of participants, "do you align as more supportive of this proposal, or less?", or worse, "which way will you bet this goes?": it doesn't invite you to share "what proposal would you confidently accept?" as a robust facilitation process does. And it produces strange game dynamics we do not have the vocabulary or time dynamics to describe. It is literally and technically "winner take all".
One may argue that "consensus or not" reflects the same functional binary output of a majority vote: but we contend that the engagement you start with, the DEMONSTRATION & LEARNING OF TRUE DIRECT DEMOCRACY through a fully consensus-oriented process, is the more valuable activity than seeking efficiency or simple participant numbers.
The online assembly proposals we have seen to date all rely on a central hub model: an open, public conference line or chat room that comprises the actual meeting space.
Our experience causes us to consider such hubs "big blinking red fucking targets."
Considering the frequency of DDoS attacks against less real-time systems operated by the OWS movement, we imagine some bad actors are salivating at the opportunity to visibly disrupt the actual mechanisms of direct democracy.
Even softer attacks which didn't disrupt the channel, but flooded it with noise or false 'votes', would be an existential threat to this approach, and one easier to enact when no physical presence is required by the attacker.
Demonstrations of this effect can be provided upon request.
We suspect that the need for a physical presence is exactly what has made the GA's model of direct democracy so effective and powerful to date. This is what we are really concerned about losing to an 'online forum'.
From a security perspective, physical GA assemblies provide the strongest authentication you can ask for. If someone gets on the "people's mic", that participant is definitely an individual human: any other participant can verify this with their own eyes, or trust that others verified. To disrupt, they have to be willing to actually show up in the first place, which few online attackers are. And if disruptive, that person can be more likely recognized on attempts to re-engage & appropriate measures taken.
In a pure online forum, none of this is a given. Changing identities, assuming multiple identities & votes, misrepresenting yourself as other people or positionalities to gain influence: all are trivial to the online participant. And they come at zero personal cost or risk to the attacker.
We admit that we are also predisposed toward localized and person-to-person action networks; we are acutely aware that relationship networks, not the mechanisms they used to communicate, were the keystone of all successful popular resistance stories of recent history, from the recent uprisings in Egypt to the People Power movement in the Philippines. We particularly encourage broader study of the latter.
Additionally, the art of GA facilitation becomes impracticable where the forum is online. First, because reading of physical cues and anticipation of formal interrupt events - like blocks - are impossible. To register your own 'soft' concerns online you have to press a button, which is deterministic in that person's mind as actually voting.
We consider real facilitation the creation of space where people don't have to cross a binary 'voting' line every time to have their feelings factored for in concrete ways. This is arguably the core problem of providing a consensus read. In that sense, there can be no real facilitation in an online, majority vote, up-and-down user experience.
Put simply, from our initial research, one could run a totally independent system like the one we describe for five years on what it would take to run the mass online forum approach for five months, from funding reliable mass scale teleconferencing and/or full-duplex VoIP / chat with mass online voting features alone. We think that should be a compelling argument.
We ask the movement in general, and the GA working groups in particular, to consider this concept as an alternative to, or in addition to, mass online forums. We understand that there is a need to engage with a broader sympathetic movement via pure online community, but we think it is a _different problem_ than democratic intra-GA collaboration. And we think this particular approach, in attempting to solve both, dilutes the direct democratic model, breaks the 'web of trust' among the physical occupations, and misdirects time, resources, & energy from maintenance of the physical spaces and other pressing concerns.
We have more detailed ideas on operational and technical details we have yet to capture in digestible form. It is our intent to work with interested parties net of their initial feedback. It is further our intent to help resource and arrange trials and production systems, once consensus and consent is established to do so, & to the extent of our various abilities.
Yours In Solidarity
@planetary_io
plntry.net
plntry@nym.hush.com