Interesting concept from the World Food Program who looks to use micro-blogging as a major means of information transfer - CipCip, inspired by Twitter, is a micro-blogging platform for humanitarian relief operations. According to the WFP Deliver project, which focuses on the delivery of information:

“Please welcome CipCip (pronounce “TJEEP-TJEEP”, Italian for Twitter) to the DELIVER family”

So how does this differ from Twitter? This statement sheds some light:

“CipCip, is like Twitter, but internal to our organisation. Access is restricted, and new users are added by invite-only at this time.”

And it focuses solely on humanitarian relief messages etc. Restricts the message getting out to the masses, like what Twitter does, and rather makes sure the message stays within the organization - seems to be Twitter with user permissions. And it is being used, according to WFP:

“Already we have had our first user ‘Ciping’ from Maputo, Mozambique. We have live streamed meetings so that we could remain working our desks while one of our team ‘Cip’d’ updates.“

Yet another innovation for the humanitarian domain.

Here’s another CAP idea I wanted to get out before I read a document I’ve been sent that may cover the same topic (just to make sure I don’t potentially draw on someone else’s idea). This concept came to me, again, last year whilst I was working on the CAENZ Public Alerting research report last year (I’m still waiting for this to be publicly released so I can link to it). My recent post proposing a browser plugin for CAP alerts is part of this bigger picture I am outlining today.

The background for it came from the realisation that there are a significant number of organisations in New Zealand that are responsible for the publication of alerts - whether to a secure group, or the general public. For example, there are 16 CDEMG Groups, 70 odd local authorities, GeoNet, MetService, Police and those responsible for infrastructure such as roads, and the Centre for Critical Infrastructure Protection.

Each of these agencies would need some means of hosting a CAP server, and incorporating some means of resilience into their CAP server(s). Given that there are potentially such a large number of CAP servers required, there are some aspects that could provide a strong and robust CAP network without seeing a proliferation of potentially fragile CAP servers. This is all built on the concept of a secure peer-to-peer network of CAP servers.

Federation
It should be possible to federate a group of CAP servers into a cluster. If we take a CDEM Group as an example, the group members may elect to deploy say 4 or 5 CAP servers to create a peer-to-peer network providing CAP alert hosting for the CDEM Group. Any authorised CAP message posted to one of the federated CAP servers would automatically distributed the CAP message to the other CAP servers in the federation. In this manner, the CAP message is instantly distributed and made available to other servers in the federation.

Peer-to-peer
I believe that the more robust approach to developing a CAP network is to base it upon peer-to-peer network technology, although tweaked to provide a secure means of publishing messages to the network These servers could of course be deployed any way to provide maximum resilience, and may be located close to major New Zealand Internet backbones, and quite possibly well outside of their geographic region. This has two potential benefits for resilience. Firstly, the message is available from multiple servers, so that the load (particularly for publicly accessible CAP servers) can be distributed across the multiple servers automatically. Secondly, should any particular server fail, the messages will still automatically be provided from the other CAP servers in the federation.

One example means by which this could be deployed is the following.

Provide a national CAP server network of federated CAP servers at key points - a nationally managed set of strategically located CAP servers. For example, Government internal CAP servers would be most likely located on the Government Shared Network (GSN) or whatever comes out of the recent restructure of this service. Public servers may be spread around both by geography and ISP (e.g. key ISPs may host a CAP server for their customers). In all circumstances these would fallback to other CAP servers in the federation in case of their failure.

Naturally, the open approach applied to peer-to-peer file sharing is not appropriate for a trusted network CAP service. To create a more secure network, something like a two-tier approach may be necessary.

CAP Publishing Servers
Private CAP publishing servers may be utilised to act as the publishing gateway to the public read-only peer-to-peer network provided by the CAP Read-only servers. Authentication, encryption and/or digital signing should be used as the basis to authorise the publication of a CAP message via the publishing server. The publishing server is responsible for verifying the digitally signed CAP alert, as well as the authentication details to verify the user is authorised to post the alert. Once authorised, the CAP publishing server publishes the alert to the road-only servers. This is the only channel to publishing CAP alerts to the network. Some form of CAP writing software (or service) may be useful for creating CAP messages and then publishing them to the servers. One protocol that may be useful for publishing is Atom as suggested by this IBM article.

CAP Read-only Servers
These are the user-facing servers that provide CAP messages to their end users. Only the CAP publishing servers are authorised to publish CAP messages to the peer-to-peer network for dissemination.

Naturally, this concept is part of a larger plan to build a CAP framework, and the circle would be able to be partly completed by designing web browser plugins that are capable of connecting to the peer-to-peer CAP read-only servers.

Widespread deployment of CAP browser plugins may mean that traditional servers may not be capable of supporting tens or hundreds of thousands of CAP clients regularly checking for new alerts. A peer-to-peer approach will probably provide the most scaleable and robust approach to disseminating CAP alerts via the Internet.

Originally posted on my blog, republished to TalkSahana.

I haven’t blogged about Sahana for a long time, and I’ve got plenty to write. So much that I can’t decide where to start, so I’m going to pick a nice small piece to start with.

The Concept

Last year, I was involved in a project in New Zealand to produce an investigative report on Public Alerting Systems with the New Zealand Centre for Advanced Engineering. This report will hopefully soon go public, and I’ll provide a link when it does.

This report was looking at the different technological solutions for getting alerts out to people in as timely a manner as possible. At one point in the search for different systems, we started discussing means of injecting HTML in web pages via an ISP, so that a public alert could be sent out to anyone on the Internet. I’ll talk about this and other options later. Let me get to the point of this post.

After starting at the HTML injection idea, and progressing through a few others, I reached a kind of natural conclusion that a more suitable means of alerting users via a web browser would be a browser plugin that can subscribe to Common Alerting Protocol (CAP) feeds, and when a relevant alert comes in via CAP, this is displayed to the user in their browser using the XUL:notificationbox at the top of the webpage.

Draft Requirements

Anyway, a possible idea for a Google Summer of Code 2009 project is that of constructing a browser plugin for Firefox that implements this alerting capability, and expanding Sahana to support full publishing of CAP alerts. Here are some features it could/should support.

Firefox Plugin

• Bundle publicly available CAP feeds (ideally listed in a nice Country/State taxonomy - this will make it easy to discover and utilise existing CAP services.
• Allow users to optionally register location in some manner, so as the plugin can identify relevant alerts (by location) and give them higher status than say remote alerts. Users should be able to register multiple locations - whether it has home & work, or multiple cities. Privacy is of course king and this information must be protected.
• Provide a means of adding additional user provided CAP feeds to the plugin.
• Provide the ability to open the alert in a new tab and format in a human-readable manner, including niceties such as embedding Google Maps to show geospatial information and links back to the source website of the alert for verification.
• Implement means of verifying messages that are digital signed, and decrypting encrypted messages.

Sahana

• Implement a CAP feed in Sahana so that Sahana can act as both a producer (in terms of creating a CAP message) and a publisher (in terms of making it available via a CAP RSS/Atom feed).
• Implement a CAP proxy or similar, so that say all users of a Sahana server can obtain CAP alerts directly from the Sahana server - rather than going to an external website. This may be useful for distribution of alerts within an organisation or centre without having every client browser connecting to an external server.

What would be very nice, but may be beyond the capabilities of Sahana servers currently, is making the CAP service on a Sahana server easily discoverable on a LAN via zero-conf services such as Bonjour.

Draft Outcomes for Assessment

The outcome of such a project would be to produce a working solution whereby a Firefox Browser plugin is capable of working with public CAP alerts and that CAP within Sahana is capable of fully acting as a CAP server via RSS/Atom feeds to the CAP alerting plugin.

Compulsory

• Implement the specified requirements
• The browser plugin works as expected with publicly available CAP feeds.
• The browser plugin works as expected against the Sahana demo server. (Yes, this means that your modifications to CAP on SahanaPHP need to be implemented).

Optional

• Implement the Sahana CAP server in SahanaPy
• Provide one or more standalone CAP clients for a mobile platform e.g. Google Android, Apple iPhone/iPod Touch etc
• Write an Internet Explorer plugin with similar functionality - it is important that this functionality is also provided for IE given its widespread usage and deployment.

Whilst the plug-in can and should operate completely independently of Sahana, it should also be designed to work well with Sahana servers (e.g. SahanaPHP and SahanaPy).

Anyway, this is just an idea I wanted to float and get out in the community for discussion. I’d welcome any further comment or ideas to build upon this!

Originally posted on my blog, republished to TalkSahana.

May 13, 2008, Colombo:
The Sahana Messaging and Alerting Module, which recently received a major face lift (well, more than a face lift: actually and overall lift ) courtesy of Respere, was presented at the LirneASIA colloquium for Disaster Management and Messaging. With an attentive audience, the colloquium was a success, and we managed to gather a lot of valuable feedback for the evolution of the module.

The Sahana Messaging and Alerting Module (acronym: SMAM) is a Sahana module that concentrates on sending messages to end users. There has been a lot of discussion on the Sahana lists and elsewhere regarding the efficiency of short/text messages during times of a disaster, and its ability to somewhat withstand the issue of messages not getting through due to network congestion problems during disasters: which is exactly why we concentrated on SMS as the primary mesaging medium for sending messages. However, having other media such as the implemented EMail functionality, and future implementations such as MMS and IM for messaging is important as well: in a period where messages reaching its recipients is doubtful, I guess duplicating the effort through various media might ensure that at least some messages get through.

I guess there are four defining characteristics of the SMAM.
1. Free/Open Source Software solution: The solution is F/OSS: thus with its transparency and large user development community, the module would definitely be improved and evolved by many developers. Even as we speak, there is a Google Summer of Code project to improve the module and build in newer features.

2. Tight integration with Sahana: The module is part of the Sahana Disaster Management System, which in turn means many benefits. Sahana consists of a large community consisting of end users, practitioners, developers, technical specialists, domain experts, researchers, academics and the like: all of whom could provide many valuable contributions to the module as a whole. Secondly, a live deployment of Sahana is bound to contain a rich dataset of valuable disaster related information. The SMAM can make use of this information in its operation: say, it has the ability to send out alerts to all people living within 100m of the coastline, making use of the People’s registries and GIS. Or possibly messages to all volunteers working in X and Y regions under Z sectors: the data being provided by the Organization Registry and the Volunteer Managment Module. Thus the possibilities are endless, and Sahana has the modules that could prove this to be a very useful aspect of an alerting system.

3. The solution is web based: is this good? Of course it is - this means that accessibility to the system is quite flexible: the system can be accessed over the Intranet or the Internet, depending on how you set it up: and consisting of the Sahana Access Control procedures, access can be controlled quite well. On the other hand, the system can be run as a standalone system as well: giving the best of both worlds

4. Finally, we built in a ‘plugin architecture’ for the messaging module. This, inspired the by the work done on the Sahana GIS stuff, allows the developer to plug in various plugins to achieve the required functionality. In the SMAM, the SMS Gateway is built in such a way: we’ve tested the system by plugging in Kannel and SMSTools as the SMS Gateways: this is quite useful, since both Kannel and SMSTools works in distinct ways and have their distinct advantages: which makes a lot sense depending on how the system is hosted, and what permissions the system has. A plugin architecture allows the developer to write interface code that will ensure that the gateway works with Sahana: and thus, any gateway can be plugged in.

More of this to come soon: I just gave a technical overview in this post.

Related Posts:
ICT4Peace - Sanjana Hathoduwa
LBO - Rohan Samarajeewa