P2P secure radio

P2P secure radio: a communications device for non-hierarchical organization of crowds

This would be a computer-based device; a Raspberry Pi should have enough CPU power to do it. It could also be done as an "app" for any smartphone or portable computing device with ad-hoc networking and the ability to plug in a headset.

Ad-hoc wireless would be the primary means of connection between devices, to prevent dependency on any central system that might be shut down, destroyed/stolen, or blocked. The contents to be communicated would be public-key encrypted, and separated by "channels" (not really channels, but more like rooms on an IRC network). Channels could be open-membership or invite-only. Channels could be publicly listed (among those with access) or hidden. Individual users could be authorized only to listen to a channel, or to speak. Anyone on the network can start a channel.

Each node would have its own unique identifier (randomly generated), and a list of the nodes it trusts (and their identifiers). When a node "trusts" another node, they exchange their trust-lists with each other. In order for a connection to be accepted between two non-trusting nodes, they would have to find a "chain of trust" between them. (In practice, a group planning a protest would probably make sure to all "trust" each other, or in the case of really large protests they could trust a smaller set of "root" nodes, just to make sure that everyone in the group can connect to everyone else without knowing them personally or by sight -- but this is not an intrinsic part of the design.)

The main point of this encryption is to prevent provocateurs from inserting their speech into the protest and from listening in to private channels -- or at least to document how they got access, if they do manage to do so, and make it possible to block them by consensus. "We found 3 provocateurs trusted by user X -- if we can't find X quickly and get this sorted out, then we need to broadcast an "untrust". (Individual users can choose to override this by "trusting" a user directly, but by default it would be accepted if it came from the original source of the "trust" information.)

Now we get to the interesting part: the voting.

The Occupy General Assemblies had a very solid democratic process for making decisions. As I understand it, anyone could:

• request to use the "human mic" to speak
• make a proposal using the "human mic"
• indicate approval or non-approval (not quite a "no" vote; more like "I'm not totally happy with this, but won't stop it") of a proposal
• block approval of a proposal (more like a "no" or at least "this needs work before I'd consider agreeing to it")

So... the device would have buttons (or would display buttons on the screen):

• to request "speak" permission on the "proposals" channel
• to switch to that channel in "speak" mode, when given permission
• to indicate approval, non-approval, or "block"

One immediate use I can see for this device, in events such as the one in the video here, would be that a large group could:

• quickly propose and agree to a spokesman to approach the police and ask questions (or make requests -- "please leave; your presence is not needed"; "release the person you are holding now, or you will be nonviolently surrounded by 200 people, and yes, we are recording you")
• relay responses (or lack thereof) from the police so that everyone knows what is being said
• propose compromise positions ("we will leave now if you will release the two people you have so far taken into custody, agree to a meeting between 3 of us and the Chief of Police in half an hour, and move out of the way") and quickly reach consensus on whether or not a proposal is acceptable

Issues

It seems likely that there would be scaling issues due to interference from many nearby devices trying to talk with each other on a limited number of frequencies. Some solutions to get around this:

• Dynamic adjustment of transmission strength: reduce power when receiver seems to be nearby (this would also increase battery life -- possibly some hardware already does this, for that reason?)
• Infrared or visible light (line-of-sight) communication as a fallback -- this is more difficult to jam and is less subject to crosstalk. If visible light is used, then the source of any interference can be identified without special equipment, and defensive measures can be taken (move into an area where the interference is blocked, shade your receiver with a hand or umbrella, fire a paintball at the jamming light-source)

Notes

• This was originally proposed on Google+, where there was substantial additional discussion on a technical level.