COWMesh Ranikajal #2 – The School In The Valley

(…continued from Part 1)
13924867_1059980900746734_8740613872229136920_nThe first time I visited the Ranikajal Jeevanshala, it was almost peak summer and the hills were baked a reddish brown from the merciless sun. Returning in the middle of the monsoon, I found the very same hills covered in a fine carpet of varying shades of green. Madhya Pradesh is an excellent place to watch nature at work across seasons. The change in colors is very stark, as stark if not starker than the fall colors of the north eastern parts of the United States.

This time around school was in session as well, meaning that in addition to the staff and their children who I had met on my last visit, this time there were an additional 200 children.

Those of us who do not run rural schools or participate in the running of them cannot begin to comprehend the kind of balancing that people who do run rural schools do on a daily and weekly basis. Managing food and lodging for 200 growing children is much much tougher than it appears.

Moreover, the region suffers endemic malnutrition, since deforestation has left most of the land un-arable or at least unsuitable for cultivation of high nutrition crops such as vegetables. This is the story across rural India. We found similar circumstances in rural Karnataka. Most of the vegetables that grow in villages are earmarked for sale in wholesale markets in the largest nearby town, which may be as much as 50-60 kilometres away.

13007262_1063843960305355_5051762933802997458_nAs a result, the local population get precious few nutrients and those usually from animal sources such as reared goats, hardy animals that can increase muscle weight even on a diet of scrub grass, and fish.img_20160827_181719

The Narmada is nearby and the Sardar Sarovar dam on the river has resulted in some stark changes in the river fauna, not the least of which are oversize prawns and silver fish. Meat and fish though require refrigeration to build a supply chain around and currently it appears that fishermen must gauge demand carefully to not end up with a catch too heavy to sell.In an environment where food is scarce, proposing a connectivity network seems almost ludicrous. All the more so for a school community that has 200 growing children to feed on a regular basis.

However, to my surprise, the school community not only insisted on paying for their own network in terms of infrastructure, they also offered me a fee for my time spent in setting up the network.

This in contrast to every other community I spoke to in the last year ( and there were many!) who found themselves unable to participate unless we, The Mojolab Foundation and associates, were willing to help raise resources to fund their participation.

I suppose it is not surprising that the school is run by and caters to the Bhil community, an indigenous Adivasi community of central India. The Adivasis I have known have always been the earliest and most responsible adopters of practices of value.

Thanks to the Ashoka fellowship program, my time was available without charge and the community was required to pay only for the hardware and the cost of my travel to the location.

I doubt there has ever been a network deployed that had to compete rupee for rupee on expenditure with nutritious vegetables and school infrastructure for under-served children, but I certainly hope there will be more.

It would be useful here to demonstrate via a thought experiment, how we think about providing value. At the Mojolab, we have a little thought experiment that we do when we need to get in the right mindset to provide value in such scenarios.

We imagine a hypothetical gram sabha, the smallest community recognized by the government of India for administrative purposes, composed of the minimum required population, i.e. 300 adult voting individuals. We further imagine that these 300 adults are all productive and employed for remuneration and all earn at least INR 32 per day, as this is the minimum amount guaranteed by government unskilled labor employment programs currently in operation in India.

Doing the math, this gives us a collective purchasing power of INR 32 X 300 individuals = INR 9600 per day.

We then design solutions and price them such that they can be expressed in number of days of earnings that each member would need to contribute in order for the community to collectively own the solution and the number of years such a solution would be expected to last based on life of components and maintenance requirements.

This of course is merely a thought experiment, since such perfectly sized situations almost never occur in practice. However, by engaging in it, the solutions architect can get into the right mind set to provide value in a community ownership scenario. The idea is inspired by a short note called “Gandhiji’s Talisman”, that used to be part of all NCERT text books when I was still in school (not sure if it is still fashionable, but have linked for the interested none the less).

Based on the specific use case, the architect may also include comparisons with existing solutions that people are already paying for.

Finally we pitch the idea to the community as an offer and proceed based on their reaction.

The real work, of course, begins after the community has accepted the offer.

In the next chapter, read how these ideas played out in the Ranikajal COWMesh story.


COWMesh Ranikajal #1 – The Biology of Connectivity

The Internet is fast establishing itself as the central nervous system of a newly evolving entity, i.e. connected humanity. For the first time in the history of our planet, a species has built a mechanism that allows members displaced over great distances to communicate instantly, using electricity as the medium. This is no smaller feat than the evolution of the central nervous system in life forms on this planet, which is the basis of identity and self awareness.

This new central nervous system interacts with the existing systems already in place, which are also electrical in nature, i.e. the biological central nervous systems in living beings.

The internet stimulates more and more of our senses every day, by making it possible to transfer entire experiences instead of just messages. However, in this race to communicate, some members of the species are being left out, almost as if marked for extinction by the larger organism.

The poor, the primitive, the aboriginal, the weak and the non-aggressive in all parts of the world are being increasingly left behind in the race to connect to the mainstream. This is not so much a sign of discrimination amongst individuals and communities, but a sign of sickness and malnutrition in the super organism being created by the inexorable advance of the internet into newer and newer dimensions.

This organism can no longer afford to grow centrally, simply because it is finding it too costly to extend a central nervous system to all parts of the species.

There are therefore two pathways from this point on.

Either the single organism that is represented by the current centralized internet will dominate and those members of the human species who fail to connect to it will simply become extinct.

The other possibility is that those who are left beyond the pale of the mainstream internet will find ways to build their own networks and find ways to interact with other networks.

Until recently it looked like the former would happen. We at the Mojolab Foundation finished the first prototype of a local wifi network model in partnership with Janastu and Servelots at Hale Kote in Karnataka sometime in the middle of 2015. However, given the cost of equipment and the gap in skill availability to use and manage a network of this sort on the ground, we spent the last year searching for the first community who would actually IMG_20160409_181253find it worthwhile to buy, own and operate a network of their own. We explored many groups, ranging from urban low income housing communities in Bangalore, to elite IIT-JEE training facilities in rural Maharashtra to members of both the tourism industry and the development community in Uttarakhand, but we were unable to establish a usecase for any of the communities that warranted expense and effort by the community themselves. It seemed that those disenfranchised by the telecommunications industry had given up hope.

IMG_20160411_165015Finally in October of 2015, we had a communication from Indore, from Shri Rahul Banerji, an Ashoka fellow and a long term grassroots worker in the Central Indian region.

Rahul da is associated with the Ranikajal Jeevanshala, a small, partly residential school run by and primarily for but not limited to the Bhil community in and around village Kakrana, District AlIMG_20160411_171810irajpur.

The school is run and managed by Shri Ninga Solanki, the headmaster and Shri G Kemat, the director along with a dedicated staff of teachers some of whom live on campus with the children. Connectivity is almost non existent as the school is in a valley and no cellphone signal reaches it.

The Mojolab Foundation’s Arjun Venkatraman visited the school in the summer of 2016, to assess the need and suggest a minimal network strategy to link the school to the Internet. Based on field experiments at the time, it appeared that the school received an intermittent 2G network signal from a mainstream ISP at one location on a hilltop within the campus. By placing a mail server relay at the network hot spot, we were able to send the first email from the school. Based on this proof of concept, we designed the #Ranikajal #COWMesh

(….see more in Part Two)

MojoMailMan – The Mail Must Go Through (painlessly!)

MojoMailManOne of the areas we are exploring via our COWMesh project is enabling service specific access based on connectivity in rural and urban low income communities. This is one of the reasons that we found ourselves unable beyond a point to support the demands of the NetNeutrality debate that recently took over Indian cyberspace.

The smartphone and connectivity environment in India, particularly in remote and rural areas is such that even if Net Neutrality was enforced, certain content would overtake others in terms of access. As a result, in our opinion any connectivity channel is worthwhile to utilize with the proviso that a parallel effort is in place with the community to enable information and content sharing across channels.

To this end one experiment we are working on is enabling reliable email access in remote areas where only spotty 2G coverage is available, in a manner that is painless for the user, with the intention of enabling more adoption of email as a communication tool in these areas.

The mechanism we’re working with is fairly simple. The local community sets up a local wireless network that includes some of the points where connectivity is available. At the points where connectivity is available we set up email servers that also act as clients. The server is configured with the email accounts of all email users in the wireless operating community. The server connects to the Internet via a mobile connection (tethered smartphone or dongle) and downloads everyones emails.

Everyone then goes to the local server and logs in to read and respond to their email.

The result is that people do not have to deal with slow loading of heavy interfaces or put up with unwanted ads just to read email. They interact with a fast local server that responds instantly at LAN speeds and later processes the email as and when connectivity is available.

To set this up we used

  1. Postfix – a Mail Transfer Agent (MTA) to send email through another server using it as a mail relay system
  2. OfflineIMAP – a tool that allows a user to synchronize online and offline IMAP accounts, to download mail
  3. Dovecot – to run a local IMAP and POP server that users can connect to, to expose a joint interface to Postfix and OfflineIMAP and also provide synchronization between local and remote authentication
  4. Roundcube – a webmail client to provide an interface between Dovecot and the end users.


We set these up on a RaspberryPi (3) running Raspbian Jessie. Some of the current assumptions we are working with –

  1. One linux user on the Pi per email user on the server – need to see if this scales
  2. User community is cohesive enough and new enough to email to be willing to put their passwords in text files on a common machine. This will need to change if and when the model scales to be able to allow users to alter their passwords without the need for the administrator to know the password. This is also part of the general discussion on roles of systems administrators in community owned and operated networks.
  3. Increasingly strong 2G signal at at least one point which can be linked to the larger inhabited area via a point to point or mesh based WiFi link (that is not the subject of this article)


Given that the above assumptions are met, here is the configuration we used for the server itself


Postfix was installed by running the following –

sudo apt-get install postfix

We are only using postfix to send mail through users external mail accounts so the only thing we need to do is tell postfix where to look for the username and password required to send mail through users accounts. This is done by adding the following lines to the end of /etc/postfix/


smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtp_tls_CApath = /etc/pki/tls/certs


The first option smtp_sender_dependent_authentication sets up Postfix to use credentials for external email servers based on the sender’s “From” field. This means that whatever mail client is used by the end user should be able to provide the users external email id as the From field while sending email. This will become relevant while configuring Roundcube later.

The sender_dependent_relayhost_maps option tells Postfix to select the external mail server to use to relay the email based on the From field as well.

smtp_sasl_auth_enable tells Postfix to turn on authetication for SMTP.

smtp_sasl_security_options disables anonymous sending of email.

smtp_sasl_password_maps tells Postfix where to look for credentials for different email IDs.

smtp_tls_policy_maps tells Postfix where to check whether or not to use Transport Layer Security for a connection with a particular email server.

smtp_use_tls sets the default policy for SMTP TLS to on.

smtp_tls_CApath tells Postfix where to find certificates for Certifying Authorities.

smtp_tls_note_starttls_offer seems to tell Postfix to note when a TLS offer was made, but I’m not entirely sure what this does (anyone who knows, please add in the comments)

After editing /etc/postfix/, we next create all the “maps” defined above.

First create /etc/postfix/sender_relay and add the following lines (one for each sender address)

<senderemailaddress> [<smtp server address>]:<portnumber>

e.g. if your email is and exposes an SMTP service at on port 587. your entry would look like – []:587

Next we create the file we referred to above in the smtp_sasl_password_maps option i.e.


and add the following lines to it – <usernameforuser1>:<passwordforuser1> <usernameforuser2>:<passwordforuser2>

<one for each external email account to be used>

Finally we create the file specified in the smtp_tls_policy_maps i.e.  /etc/postfix/tls_policy and add the following line (one for each external mail server  –

<server address>:<port number> encrypt

e.g. in the for the server above if you wish to enable TLS the line would read – encrypt


After this we create the hashes of these files that Postfix will actually use by running the following commands –

sudo postmap /etc/postfix/sender_relay
sudo postmap /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/tls_policy



We installed OfflineIMAP by running

sudo apt-get install offlineimap

At this point we have to set up each users email account (Note: this should be replaced by a web based admin package, possibly vimbadmin or postfixadmin).

In each users home directory, edit the file .offlineimaprc and add one local and one remote repository as below for each email address that the user wants to access mail from.


accounts = GMail, OtherGMail

[Account GMail]
localrepository = GMailLocal
remoterepository = GMailRemote
autorefresh = 2

[Repository GMailLocal]
type = Maildir
localfolders = ~/Maildir/Gmail

[Repository GMailRemote]
type = Gmail
realdelete = no
remoteuser =
remotepass = password1

[Account OtherGMail]
localrepository = OtherGmailLocal
remoterepository = OtherGmailRemote

[Repository OtherGmailLocal]
type = Maildir
localfolders = ~/Maildir/OtherGmail

[Repository OtherGmailRemote]
type = Gmail
realdelete = no
remoteuser =
remotepass = password2

The options above are described below :

accounts : Lists all the accounts associated with the user, separated by commas

type: Type of account, IMAP/Gmail/other

remoteuser/remotepass: Username and password for the remote repository

realdelete : Tells OfflineIMAP whether to delete messages from the server when they are deleted from the local repo


To test if the configuration is working, run:




Now that we have both sending and receiving configured, we will configure Dovecot to manage access to them by a webmail client as well as authentication

To configure Dovecot first we enable the appropriate protocols by editing /etc/dovecot/dovecot.conf and setting the protocol option

protocols = imap pop3 lmtp

Next we edit /etc/dovecot/conf.d/10-auth.conf to tell Dovecot how to authenticate users. To do this ensure that the line #!include auth-system.conf.ext is uncommented.

Finally we tell Dovecot where to find email for each user by setting the mail_location option in /etc/dovecot/conf.d/10-mail.conf

Configure the appropriate inbox by setting the namespace (this is relevant for multiple addresses and needs further explanation)

mail_location = maildir:~/Maildir/:INBOX=~/Maildir/Gmail/INBOX:LAYOUT=fs
namespace inbox {
  separator = /
  location =maildir:~/Maildir/Gmail/:INBOX=~/Maildir/Gmail/INBOX:LAYOUT=fs
  inbox = yes
  list = yes
  subscriptions = yes



Lastly we need an interface or what is known as a Mail User Agent or MUA to act as a client to Dovecot and allow users to access their email.

To do this we used Roundcube, a webmail client that is also installed on the server. Of course, individual users are free to use other clients as they wish, but the Roundcube interface provides a web based one.

To install Roundcube we ran –

sudo apt-get install roundcube

To configure edit /etc/roundcube/ and set the following options

// The mail host chosen to perform the log-in.

$rcmail_config['default_host'] = 'localhost';

// TCP port used for IMAP connections

$rcmail_config['default_port'] = 143;

// IMAP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or null to use
// best server supported one)
$rcmail_config['imap_auth_type'] = null;

// If you know your imap's folder delimiter, you can specify it here.
// Otherwise it will be determined automatically
$rcmail_config['imap_delimiter'] = null;

// SMTP server host (for sending mails)

$rcmail_config['smtp_server'] = 'localhost';

// SMTP port (default is 25; use 587 for STARTTLS or 465 for the
// deprecated SSL over SMTP (aka SMTPS))
$rcmail_config['smtp_port'] = 25;
// SMTP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or empty to use
// best server supported one)
$rcmail_config['smtp_auth_type'] = '';

Having set these, we restart all services and once they are back up, users can log in and access their email for both sending and receiving by going to


and logging in as the linux user they have been assigned. After logging into Roundcube, each user will have to add one identity each for each of the mail addresses that they wish to send email from by going to the Identies section under settings and filling in the form.

Screenshot from 2016-05-03 21:06:47







References –


From Pyramids to Meshes – 2006 to 2016

Recently I was looking back at the origins of our work here at Mojolab and I came across an old pair of documents from 2006. At the time I was a fresh engineering graduate working two jobs and trying to get a fellowship at Stanford to work on building what I called at the time, an “Alternative Information Architecture” for Chhattisgarh, which was a focus area for two generations of my family. At the time, this is the definition we had of an “alternative network” –

Introduction to Alternative Networks
For any community aiming to share information efficiently with a view to participation in
development, an efficient communication network is mandatory. Communication networks are
usually perceived as being a set of hardware to perform the physical transfer of data and a set of
protocols, which govern the transfer. However, in most definitions of communication networks the user’s significance is somewhat suppressed. The individual using the network is perceived as an external agency, not really a part of the network. The developments that may occur as a result of human interaction with the system are also seldom taken into consideration at the time of design. The result is that the benefits from incorporating each user of the network as a network
component are overlooked. Alternative networks, which aim to diverge from the existing traditional network models, can be of many types. The common factor among all such networks is that they aim to de-centralize and make informal the process of communication.

What’s interesting to note is that while I was able to articulate that the type of network needed would be an “alternative”, I really didn’t have a clear articulation of why it was an alternative or what it was an alternative to. If I was to rephrase myself today, I would call it a hybrid mesh network consisting of multiple channels at multiple layers/levels of the network each connecting to one or many nodes as an alternative to a network of stars or a tree with clearly laid out hierarchies.

The means of change from a hierarchical model to a networked peer driven one would be superseding rather than breaking the hierarchies already present by creating new interlinks complementary to the existing ones.

The notion of incorporating the user would remain as is, though I would further elaborate that the role of the user would be to simply increase his/her own data acquisition and dissemination capability by learning more skills. The measures of this could be the number of channels that a user is adept at using for communication.

At the time, the essential or defining characteristics that I could come up with for any such alternative network were as follows:

Definition of an Alternate Information Architecture
The most attractive fact about an alternative architecture is that it is extremely conducive to
The primary concepts that this alternative architecture will use are
• Layering
• Self Organization
• Self Sustenance
• Robustness and Self Healing
• Collective Intelligence

In hindsight, the layering model I had in mind at the time was somewhat limited by my limited field experience. As a result, the descriptions of the layers below end up taking a rather hierarchical form, which is counterproductive to the goal of decentralization.

Tier 1, Information Gathering
Grassroots level information gathering, by “barefoot journalists”, who would be trained minimally.
The data at this stage could be in audio form, or, if the “barefoot journalist” is educated to some
basic level, then written formats could also be used.
The skills required by the members of this tier would typically include: a) an ability to recognize
information relevant to the community, b) self-motivation and enthusiasm and c) basic aptitude
towards learning.
The members at his tier could also be involved in making efficient use of the oral tradition of the
region to disseminate information.
Tier 2, Compilation and basic editing
Compilation of information gathered by “barefoot journalists” into digital form and basic editing.
This would involve conversion of audio material into text for dissemination on the Internet, basic
editing on the text matter to ensure that relevance and consistency is maintained and finally
categorizing the information. The skills required by members at this level would be a) ability to
use a computer with reasonable proficiency b) ability to analyze large amounts of data c) basic
aptitude for editing d) ability to recognize relevant information
Since this tier is intended to be involved in basic editing and compilation, a fundamental level of
error checking would be required. Also on the information dissemination side, this tier would be
responsible for some routing of the information to the various sections of the community.
The members at this tier would also be responsible for spreading awareness about the usage of
the architecture to obtain information. They would be required to demonstrate the website use to
other members of the community. In addition to this, they could be involved in the dissemination
of audio-visual content in areas where literacy and connectivity is low.
Tier 3, Planning, Management and Dissemination
Collection of compiled data from Tier 2, classification of the data into different sections for easy
user access and dissemination through the CGNet website. This level would involve some degree
of technical know-how. The skills required for this tier would include

  1. ability to create and manage web content,
  2. basics of local language computing and
  3. ability to present information in a manner that can be effectively received and used by the community.

This tiered architecture was in fact implemented in the form of CGNet Swara by 2010, where the Tier 1 participants reported and listened to content using mobile phones, which require a minimal amount of training to use effectively. Tier 2 consisted of a verification and moderation network and Tier 3, i.e. the online tier was social media.

This implementation was key in helping us understand the inherent limitations of the hierarchical layering structure. As the diagram below shows, the flow of information in a hierarchical structure is vertical. pyramidWhile this does not prevent horizontal information flows, it also does not acknowledge or leverage them. As a result, the costs of information transfer in a hierarchical system rise as the system scales since all information must first rise from the bottom to the top and then descend again, ostensibly in a filtered and value added form. However, the cost benefits of such value addition must be compared to the cost benefits of horizontal information transfer where members are free to share information irrespective of their position in the hierarchy and the “quality” and “credibility” of a source is based on peer review rather than hierarchical accreditation.

The other issue with the model as described in the paper is that it assumes a uniform access to the Internet. Considering that I wrote this in 2006 and Internet access still remains very fragmented even 10 years later, clearly shows the fallacy of this assumption. Further more, while the model takes into account the effort in curating incoming information from the grassroots, it does not acknowledge or measure the effort in sending information to the grassroots.

Given the condition of Internet penetration and the asymmetry of useful information vs noise on the Internet, the data dissemination cycle needs at least as much effort as the data acquisition cycle.

When one takes this into account, it becomes evident that any entity that implements equal rigor in data collection and dissemination can only be a peer with the other elements of the network and the efficacy of an entity as a network member would be measured not by hierarchical certification but by the number of channels it operates in. In other words, PiFiTV-FullMesh2the credibility of an information source would be based on number of people it interacts with and number of people who interact with it, rather than by how effectively it talked about its “processes” and how many people it “certified”.

The result will likely be much messier…but much more colorful!

The full paper and abstract are linked below. I will be posting further updates to this train of thought as the analysis continues.


CGNet RDVP Abstract

CGNetIA Project Proposal

Disks on A Plane – Building The New Information Supply Chain

FlyingDiskBy way of open source development where possible and piracy where not, new innovation is enabling communities and individuals to experiment with building, owning and operating communications infrastructure. This is enabling strengthening of localized communication. At the same time the global nature of the Internet and the new opportunities it presents for peer to peer collaboration are resulting in virtual communities being created on the Internet that augment local communities and provide access to content that would not be available locally. New hybrid models of communication and information sharing are being invented and experimented with. In addition to Mojolab’s own experiments with mechanisms such as data muling and locally operated COWMesh networks, Learning Equalities’ Kolibri project seeks to bring the benefits of a digital classroom and current content to communities beyond the pale of the Internet.

We re-did our thought experiment of muling data on a railway journey, this time with a larger data packet size and then we tested it out in part by muling some data back and forth between Bangalore and Kakrana, a remote village in Madhya Pradesh, via Bhopal.

The though experiment revealed the following –

Screenshot from 2016-02-24 13:56:05Screenshot from 2016-02-24 10:02:28








On practical experimentation –

I downloaded a total of 25GB of data on my home connection –

Initial data download (MB) 25600
Rate of data acquisition (INR/MB) 0.0111816406
Cost of data acquisition (INR) 286.25


Total data transacted over journey


Date Data Rcvd (MB) Data Given (MB) What Cost
10/04/16 42.6 0 R resources 0
14/04/16 272998.4 0 Ranikajal Data 0
14/04/16 27238.4 Arjun Brought 0
Total (MB) 300279.4


Had I attempted to perform the same transaction over a 3G connection @ INR 250 per GB or ~INR 0.25 per MB, the cost of transaction would have been .25 * 300279.4 = INR 73310 plus change.

As it happens, the cost of my travel (by air conditioned train) cost less than INR 5000 in total (up and down). This puts the cost per MB of my mule based data transaction at about INR .015 per MB.  Which is about 1/14th of the cost per MB that 3G would have provided.

You can imagine our enthusiasm therefore to get tools like Kolibri and KALite on to a plane quickly!


Barriers to Scale – Growth vs Replication

growth vs repThis time in 2014 I was working the Ashoka Globalizer team in preparation for the Globalizer Summit in Bonn in June of that year to evaluate the work we were doing in terms of its readiness for global scale. The Globalizer exercise came with the great privilege of working with a world class consulting team comprising of one global entrepreneur and Ashoka fellow and two analytical experts from McKinsey and Co. Working with this distinguished team, we crunched up the numbers from our work with CGNet Swara, a pioneering citizen journalism effort and our flagship project at the time. Our goal had been to analyze whether the model, i.e. using a localized interactive voice response system to create a voice based bulletin board or “audio portal” for newsgathering and community interaction from remote areas where media and the Internet had not penetrated, was ready for global application and scale.

The indicators at the time seemed to suggest that it was, since we had replicated the technology successfully for use-cases in Afghanistan and Indonesia. However, on analyzing the numbers we realized that while the model was very successful in terms of bringing content out of and into media/connectivity dark regions, the cost at which it did so was not strictly sustainable unless an external party or parties were willing to support it.

While differential costs of communication and data access as well as policy plays a major role in determining the cost of a technological intervention of this nature, an equally significant role is played by the design of the system and its intended scaling strategy.

For a system that seeks to retain its character through the course of scale, whether in the interest of maintaining quality or preserving brand value, the costs of scaling are significantly higher.

In the case of CGNet Swara, what we learned was in line with what we had been told by experts from Google fairly early on. The two major impediments to scale were 1) the fact that the project sought to remain completely free for access by users, on the pretext that they would otherwise find it too expensive to use and 2) the need to maintain a centralized moderation strategy that filters content prior to release.

Both of these strategies were initially employed to engage users and maintain quality.

To attract a largely low income population to use the system, the design was set up to respond to a “missed call” placed by end users with an outgoing call from the system. The end user therefore ended up paying nothing. Had a telecom operator been supporting the system, this would have been infinitely sustainable. However, the project was paying retail prices to purchase telephone airtime, which while infinitely cheaper than broadcast media was still quite expensive at scale, resulting in a large cashflow requirement. Had this been distributed by encouraging more replications, the costs of data collection could have been distributed.

Since the platform was initially implemented by individuals who were solely liable for the content being released, the choice to filter certain content was made to ensure continued operation of the platform free from state intervention. What the team failed to take into account was that this was relevant only as far as the platform was publishing news anonymously on behalf of callers. When the decision was made to publish the users name in the interest of transparency, the responsibility of the content was already on the user. At this point, the filtering mechanism could have changed from a “screen and release filtered content” to “publish and remove reportedly offensive content”. The requirement would have been to explain the liability of publication clearly to users via a terms of use communication.

Had these two mechanisms been employed, the system could have evolved to being an aggregator of content from several replications, which would have been a far more sustainable and scalable option.

We have seen similar patterns in most other technological interventions. The need to maintain centralized control and ownership often prevents organic scale that could come from free replication.

With this learning, we have since been working on ways to enable more replication than growth in our projects. The growth element is now redirected towards growing capacity as well as enabling growth in numbers of replications rather than growing a single system

For example, with our COWMesh project , we have taken the approach of not directly implementing solutions for communities but to enable communities to set up their own systems after observing what is possible on demonstrative systems which Mojolab maintains and travels to community locations with.

Given the gap in skill availability at the grassroots and skill requirement to use open source tools, we have simultaneously been working on setting up mechanisms to train more and more people at the grassroots who can then utilize their skills locally. This element of our work is where we currently need the most support.

We therefore invite collaboration from anyone who wish to improve skill availability at the grassroots.


Red Queen! – Low Tech Dev in a High Speed World

redqueenI’m currently fighting a battle with a hardware vendor to get a piece of equipment replaced. The particular equipment in consideration is a router to be used by a school in remote rural Madhya Pradesh that has been functioning for over a decade with very little resources. Should my efforts be successful, they get email access. However, at the moment, the device in question is refusing to cooperate with the design I am trying to implement with it, resulting in my needing to get a replacement or a resolution from vendor or manufacturer. Should I fail to get such replacement or resolution, I will be left with a choice between absorbing the loss of a router (i.e. INR 7000) or passing it on to the “customer” i.e. the school.

In a regular commercial scenario, this would be a no brainer. The dealer/vendor NEVER absorbs a loss. However, commercial scenarios often assume peer relationships where none exist. For a   corporation or research lab with a large technical budget the loss of one piece of equipment would not be a huge one. Collateral damages of research are considered an acceptable expense head in most cases. For low budget exercises on the other hand, each setback represents real expense and loss of opportunity to use the same resources elsewhere. As a result either I as the researcher or the school as the consumer has to take a hit.

Our current situation points to an increasingly prevalent situation faced by people who implement technology for low income/low commercial consumption groups. Open source technology, while cheap and free to use is seldom stable enough to be used by consumers with limited skill. The situation is not made easier by hardware manufacturers who sometimes by design and sometimes by accident develop hardware which does not meet existing standards, resulting in new development being needed before the hardware can be used with open source systems. Development, irrespective of who does it, comes at a price measurable in person-hours, which adds to the cost that has to ultimately be borne by the end user. Finally, governments have been increasing the level of control that they exercise on technology steadily, meaning that several open alternatives are now simply unavailable by statute.

As a result, groups like the Mojolab, who are at the border of technology development and usage are faced with the need to constantly evolve strategies and often use non intuitive means to achieve intuitive ends. It is akin to running very fast simply in order to stay in the same place. In evolutionary terms, this is called the Red Queen phenomenon, inspired by the Red Queen’s chessboard sequence in Alice in Wonderland

“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else—if you run very fast for a long time, as we’ve been doing.”

“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”

Lewis Carrol, Through The Looking Glass, Chapter 2



COWMesh Ranikajal #0 – Building Networks in Connectivity Choked Rural India

DSC03027Earlier this month I was at the Ranikajal Jeevanshala school in Kakrana, Madhya Pradesh, studying the region for possible applications of the COWMesh network design that we have been working with.

Connectivity in India is interestingly distributed. The Internet is penetrating every day into new and hitherto unreached areas. However, and this is a big however, the quality of connectivity varies drastically between different areas. In most newly connected locations the best possible data connection that can be found is a 2G network that experientially feels like an old 56k modem line to use.

Even this connectivity is quite welcome as it is perfectly adequate for text browsing and email. DSC03056However, GMail and other popular webmail services now come with extremely heavy interfaces (all that AJAX and Javascript-y stuff that keeps pulling data from the server “on-demand”), which are extremely hard to use on slow connections. Furthermore, even where a fast connection (like a 3G) is available the cost of data is quite high, considering that rural India is has traditionally been viewed as a low income region. The current retail rate for 3G is about INR 250/GB. This means that a standard 120 minute mp4 video would cost almost 180-200 rupees. Compare this with the price of  DVDs which often contain several 120 minute videos for the measly price of INR 40, or even with the price of an SD card, which retails at about INR 280 for a 16 GB card, which can be re-used and overwritten.

DSC03036The Ranikajal team, which has recently seen the addition of outstanding ex-DAE scientist Shri Swapan Bhattacharya, originally envisioned using the COWMesh to create a wireless link to the nearest location where 3G connectivity is available to bring fast Internet to the school.

As part of our survey and following discussion we observed that the vantage points where we would need to set up hops in order to connect Kakrana to the nearest 3G connected locations, i.e. Dahi or Kulvat, were largely uninhabited. Therefore setting up and maintaining routers in those locations would not be feasible.

Further, 2G network access was working via Airtel on the school campus, at a hilltop and it appeared to be far more feasible to set up a local mesh to connect the top of the hill to the bottom and then provide a link into the village. Since full scale browsing on the new graphical web is not really feasible using the 2G network, we concluded that we need to set up a mechanism to provide email access. The way this would work would be that a local mail server running on a Raspberry Pi would be attached to the wireless router on the hill. The Pi will be connected to a smartphone over a usb tether to provide an internet connection, which will be share over the mesh. A dongle may also be used, though our experience tells us that mobile phones are best optimised for using low bandwidth high latency connections, provided of course that advertisement downloading apps can be weeded out.

DSC03100The mail server will download emails from the users accounts whenever the connection permits. Users in the school and anyone else on the mesh with an account on the local mail server can access and send emails through it. This would allow users to use email without the slow experience of trying to load a rich web interface through a slow connection.

System is currently being built. More posts to follow on testing and application.

(Update – We are using OfflineIMAP and Postfix with a Roundcube interface at the moment)


COWMesh Demo At Servelots – Pics and Audio

Last week we did a first cut of the mobile COWMesh  demo at Servelots in Bangalore. Audios of the first half of the demo and pictures below. More audio to follow as it gets edited!

Continue reading “COWMesh Demo At Servelots – Pics and Audio”

स्वतंत्र लोग, मजबूत नेटवर्क


सामाजिक कार्य करने वाले लोगों एवं सन्स्थाओं की दुनिया में अधिकतर व्यक्तिगत असहमतियों और मनमुटाव की स्थितियों का तांता बन्धा रहता है। कई बार हम इन असहमतियों और मनमुटावों के बीच सामजिक कार्य के मूलभूत सिद्धान्तों से इतने दूर हो जाते हैं कि सामाजिक कार्य भी हमें असामाजिक सा बना देता है।


फिर भी किसी किसी दिन कोइ ऐसी खबर सुनने को मिलती है कि मन प्रसन्न होने के साथ साथ सामजिक होने की इच्छा फिर प्रबल हो जाती है और हमे सामजिक कार्य में जुटे रहने के लिये नई स्फ़ूर्ति और ऊर्जा मिल जाती है।


ऐसा ही कुछ पिछले हफ़्ते हुआ. हम ऐन्टहिलहैक्स की तैयारी आरम्भ ही कर रहे थे कि भोपाल से हमारे पुराने साथी अनुराग दुबे का फोन आया और उन्होने बताया कि वे हाल ही में डाल्टनगंज, झारखण्ड स्थित सन्स्था “मज़दूर हूं मजबूर नहीं” के लिये एक मोजो बोल सर्वर लगा के आये हैं, जिसका उपयोग सन्स्था अपने साथ जुडे जन समुदाय से सम्पर्क बढाने के लिये करेगी. “मज़दूर हूं, मजबूर नहीं” मुख्य रूप से मनरेगा को सही रूप से लागू किये जाने मे आने वाली बाधाओं का निवारण करने एवं मज़दूरों को उनके पूरे अधिकार दिलाने के लिये कार्य करती है।


संस्था का कार्य तो सराहनीय है ही, पर हमारे लिये खास बात यह रही कि सर्वर लगाने का निमन्त्रण अनुराग को श्री राजू राणा से मिला, जो कि सी जी नेट स्वर से लम्बे समय तक जुडे रह चुके हैं. राजू ने ही अनुराग का सम्पर्क मजदूर हूं… के मिथिलेश जी से करवाया. गत वर्ष तक मोजोलैब और सी जी नेट साथ मिल कर कार्य कर रहे थे, पर पिछ्ले कुछ महीनों मे दोनो ही समूह अपने अपने कार्य में अधिक व्यस्त हो जाने के कारण एक दूसरे से सम्पर्क बना कर नहीं रख पाए हैं.


राजू सी जी नेट द्वारा प्रशीक्षित जन पत्रकार हैं और अनुराग मोजोलैब द्वारा प्रशीक्षित जन अभियान्त्रिक। राजू और अनुराग, दोनो ही ने प्रशीक्षण हैकरग्राम भोपाल में लिया। दोनो को बिना सन्स्थाओं पर निर्भर हुए एक साथ कार्य करता देख सचमुच लगता है कि हमने पिछ्ले कुछ साल व्यर्थ नहीं गवाये। मोजोलैब और सी जी नेट, दोनो ही की प्रबल इच्छा रही है कि हम कार्यकर्ता प्रशीक्षित करें, कर्मचारी नही। आज राजू और अनुराग ने यह कार्य कर के हमें आश्वासन दिया है कि हम सही दिशा में बढ रहे हैं। हम राजू और अनुराग के आभारी हैं और उनसे निवेदन करते हैं कि इसी प्रकार कार्यरत रहें। हमारी शुभकामनायें और सहयोग हमेशा आप के साथ हैं।