Design and Implementation

Developing for OLPC
The OLPC project was designed with collaboration in mind. Software packages, called Activities, can be shared amongst users on an Ad-Hoc or Mesh network. An activity is a bundle of Python code and all associated libraries. Our activity is an OLPC activity that is shared between XO Laptops (XOs) using an Ad-Hoc network.\footnote{The OLPC project has released several generations of Laptops, including the XO-1, XO-1.5, and XO-3.} The activity uploads messages to an Ushahidi deployment when Internet access is detected, and shares messages between XOs connected to the same Ad-Hoc network.

When an XO joins a shared activity, it broadcasts messages and cures to other XOs participating in the activity. The groups of messages and cures are received in batches. When a batch of messages is received, they are serialized and stored on the device's flash memory. Our application currently checks for Internet connectivity every 15 seconds.  If an XO finds Internet connectivity, it uploads all uncured messages to the Ushahidi deployment, and downloads all known cures. As we discuss in our future work section, the length of this timer is arbitrary and a variable length timer may prove more useful.

Our design considered security, but for reasons of time and simplicity we have yet to implement these features. Message privacy from any user to the Ushahidi server is easy to guarantee by including the public key of the server with the application bundle. Since information contained in messages may be valuable to those nearby, it is preferable to guarantee integrity for all messages by appending a message hash to each message, but only encrypt messages if a user explicitly marks the message as private.

This prototype activity is designed to be simple and easy to use, and to require a minimum amount of user interaction. It consists of a single page, with two panes. The top pane is used to create and send messages, and the bottom pane displays all sent and received messages. We envision a use case where a child composes her messages in 'laptop mode', then switches to 'game mode' where the laptop is closed with the screen facing outwards. The XO is very lightweight, and in this mode can be carried by its handle or attached to a vehicle, bag, etc. There are buttons on the face of the device, so a user is still able to view and scroll through incoming messages in this mode.

We would greatly appreciate assistance by any experienced PyGTK developers who would like to assist in building a more email-client style GUI.

Implementation of Shared Messages
We use an epidemic messaging scheme for sharing of all messages and cures. Since we do not prioritize the transfer of cures over messages, our application uses passive cures. While other delay-tolerant messaging schemes are more efficient, we feel it is important to maximize message delivery probability.

To accomplish data synchronization, we utilized a library for shared data structures and activities on OLPC called groupthink, which enables the creation of shared data structures. This allowed us to utilize a data structure called a CausalDict, which is a Python dict (or hash table) that is automatically shared between all XOs which have joined a shared activity. We use two CausalDict objects, one containing all messages and the other containing all cures. By using a hash derived from the message as the key, we ensure that all copies of a message are cured. Messages are simply tuples containing the title, content, category, location, time, and message hash.

One reason the OLPC is well suited to peer-to-peer applications is that it was designed with ad-hoc collaboration in mind. OLPC designed the XO with an infrastructure free 'children sitting under the tree' scenario as a primary use case. This sharing is primarily accomplished by two services, an interprocess communication system called D-Bus and a real-time communication framework called Telepathy. Telepathy allows applications running on different machines to communicate via an abstraction called tubes. Tubes are used to pass text and data, and can be implemented via a number of backend Connection Managers or protocols.

XOs use the Telepathy Salut protocol when connected to an Ad-Hoc network.  On the network layer, Telepathy Salut uses multicast DNS (mDNS), and link local Extensible Messaging and Presence Protocol (XMPP) for device and service discovery. The XMPP protocol enables server-less messaging between clients via mDNS.  Multi-user messaging, and therefore activity collaboration on the XO, is accomplished via an extension of XMPP called the Clique protocol.  Unfortunately the Clique protocol is very inefficient. One of the *first* priorities of this project is to  reduce the overhead by implementing our own UDP broadbast based sharing mechanism.

Uploading to Ushahidi
When an XO is connected to the Internet, it uploads any of its uncured, or unreceived, messages to a Ushahidi server via HTTP. Ushahidi allows for developers to extend its functionality via modular plugins.  To accommodate cure functionality, we wrote a plugin that creates a cure whenever a message is uploaded. As mentioned earlier, each message is identified by a unique hash value.  We store each uploaded message hash as a cure in a separate MySQL table.  By extending Ushahidi's RESTful API with our plugin, we enable users to query this table via HTTP which results in a map of all received messages hashes and the time that message was first received by the Usuahidi server. These cures are then distributed epidemically to neighboring XOs.  Since our design relies so heavily on an available Ushahidi server, we wrote a deployment-ready plugin that easily integrates into any existing Ushahidi application. We would like to extend the Ushaidi plugin's ability to include photo, audio, or video attachments.