E-Democracy Pages Wiki

Search Wiki

 

Tools

 

Electronic Block Clubs

From E-Democracy.org

Revision as of 12:41, 19 February 2013 by Wbushey (Talk | contribs) (Protocol/API)

Core Idea

  1. Assume a leader in the center for an online group at a block or building level.
  2. Support that leader so they can easily create accounts for those who will likely not self-serve. Street addresses will be geo-coded by the system.
  3. Assume that E-Democracy will go door to door, etc. to reach 80% of households in a few areas/buildings of 50 to 200 households to sign people up. At least one of the areas will have a large non-English speaking population.
  4. Design group communication alert preferences to allow a normal channel and an urgent channel. Have primary and secondary language preferences.
  5. The normal channel will default e-mail notification with full-text, link to audio file(s). Other less invasive options will be available.
  6. The urgent channel will default robo-call on telephone with SMS or e-mail alternatives. (There probably needs to be some sort of don't call after 9 p.m. option)
  7. Posting options via e-mail key: near@site.org urgent@site.org (in addition to web, sms, tele)


Scenarios

Small Group

Focus on a tool for the block connector to use to foster mostly private exchange among most of their neighbors whether they are online or not. Telephone/recorded voice, sms, e-mail, web, ... maybe IM alerts with a personalized normal and a priority channel. Most information will be one-way from the block connector, but two-way will be assumed with members empowered to share. This is all about leveraging VOIP Drupal/Vojo.co/MyVoxBox.org. There is a leader in the center deciding who is an and out of the group, so Alpha testing would leave out fancy registration with geo-coding. Some rough gathered notes: http://bit.ly/XuIxgO

Geo-Messaging

A possible Drupal module where the members usual street address is mapped to their "usual" longitude and latitude. Option for multiple addresses like work or cabin. Then add some sort of scheme where a site can determine (or the member) the number of X closest people who may send them a geo-group message and where the group can then be taken to read it. The author could determine its visibility - circle of X nearest people only or public and would own it in terms of deleting the topic. This module could be used widely by other Drupal sites and therefore engender open source collaboration.

Map/Directory

Use Drupal to host a directory of local online groups, place blogs, neighborhood association websites and facebook pages, etc. with a mapping option to display groups covering a specific bounded territory, a dot for a specific block or building (it could be bounded if zoomed), and perhaps a radius for a group tied to a focal point state of mind (Uptown). This is the BeNeighbors.org "Got Milk?" promotional directory idea: http://pages.e-democracy.org/BeNeighbors_specification

Neighbor Connecting

Advanced sorting or match-making function to connect neighbors based on needs, offers, interests, etc. (There must be something out there in the dating service world on Drupal that could be used.) This rolls into the collaborative purchasing and bidding area too like coordinating alley snow removal.

Existing Tools and Technologies

VoIP Drupal

Group (Geo) Messaging Architecture

Here is a first rough draft of a system architecture that implements the scenarios and ideas discussed above and at the Drupal meetup. It is designed to allow for piecemeal development, flexibility of platforms, and to be generalizable to other initiatives that might wish to use or develop a multi-medium group messaging system. It is far from complete, but it hopefully provides a starting point.

Group Messaging System

The kernel of the architecture is the Group Messaging System (GMS). The GMS is responsible for storing user information (including contact information and locations of significant places such as home and work) and messages. Messages are delivered by Interface Services (described below). The GMS is also responsible for relaying messages to members of a group via the Interface Services. Except for user management and administration pages, the GMS does not provide a user interface - this is the responsibility of the Interface Services.

Components of the Group Messaging System include:

  • User Information Database - Stores information about users’ contact information and preferences.
  • Messages Database - Stores the content of messages delivered to the GMS and the intended destination group.
  • Group Controller - This defines and implements a “group”. When a message is received, the Group Controller is responsible for deciding which users should receive the message, and when, based on its definition of a group. This component is really an abstraction (an interface in the Java/C++ sense). Plugins would define what a group is, allowing for different initiatives to customize a “group” for their needs. Plugins can also modify the above database schemas.
  • Administrative Website - Provides a way for server/site administrators to administrate. Probably can be augmented by the Group Controller.
  • Profile Management Website - Provides users a way to create and modify their profiles, which includes contact information and preferences. (Upon reflection, this might belong in the Interface Services). Probably can be augmented by the Group Controller.
  • API - Implements the protocol through which Interface Services communicate with the GMS. This API allows Interface Services to deliver and receive messages. A basic API is provided by the core GMS, but Group Controller plugins can augment it.

Interface Services

Interface Services are responsible for allowing users to interact with (i.e. send and receive messages) the GMS through various mediums, such as the web, email, and phone. Each Interface Service is responsible for one medium, and relays user interactions from the medium it covers to the Group Messaging System’s API.

Examples of mediums that Interface Services would be created for include:

Protocol/API

Not much thought has gone into the specifics of the protocol used to communicate between the GMS and the Interface Services. Its implementation will likely be based on currently popular web protocol paradigms (some combination of REST, RPC, XML, JSON.) The protocol might also be inspired by (or simply an implementation of) SIP or XMPP. At minimum, the protocol has to allow the Interface Services to:

  • Register with a GMS instance
  • Send the content, destination group, and some location information, to a GMS
  • Request messages destined for a user from the GMS

The Protocol also has to allow the GMS to:

  • Deliver messages to users through the Interface Service
  • The Protocol more than likely also has to allow for user profile CRUD.
 

Home - Mobile - Forums - Wiki - Blog - About - Help - Contact - People - Donate - Rules - Archives