The Difference between Repeat (RPT) and Retweet (RT) on a Mobile (sorta)Mesh

There are two behaviors I have been considering during my adventures in human-powered mobile mesh these last few weeks. The first is Retweet or Reshare, as invented by Twitter users manually (“RT @foo this is important”) and then later on built directly into the Twitter platform as a feature. The second is “Repeat”, as inspired by radio repeaters.

Retweet (RT) is meant as a human-powered endorsement of a message. The meaning and content of the messages have been ideally verified, or at least the source is trusted.

Repeat (RPT) is meant to allow a message to extend further in its reach, by allowing the receives device to reshare it another 10 to 100 meters from its current and future positions. It is an active way to participate in extending the mesh, but it should not be seen as endorsement of fact or an act of verification or trust.

A mixture of retweeters and repeaters in a crowd, can then extend the reach of a message from 10m or 100m up to say, 400m in the drawing below. A repeater might be a fixed device, say a phone or tablet with a good solid antenna plugged into a battery pack or an outlet somewhere.



A retweeter is more likely a person in the crowd, moving through the area in a variety of directions. As they continue moving however, they will keep rebroadcasting their last few tweets, including the retweet. As they encounter new receivers / lurkers, they will receive the original message, and the mesh is now extended in a non contiguous-manner.


The Gilgamesh app supports a simple two-tap feature to manually reshare any status message you have received. Once this is done, your device then rebroadcasts the message over its Bluetooth and Wifi radios, with the expected “RT @900734 i am live on air” format. Also, remember beyond this particular app, any user can manually set their Bluetooth device name, be it a laptop or an iPad, to use a similar format. The app also now supports an automatic repeater mode, that can be easily toggled off and on. In this mode, *ANY* message you receive is automatically rebroadcast, using the “RPT @900734 does the repeater hear me” syntax. You can see this in the screenshot below.
device-2014-10-06-165429  device-2014-10-09-120044

Ultimately, because we are limiting this experiment to a very simple plaintext status messaging system, we have made our lives very easy, and made the possibilities of successful use quite good. Since we aren’t concerned with routing internet protocol or creating a reliable LAN network that can sustain HTTP, we can take advantage of ideas like non-contiguous meshes, retweeting and repeating to extend the range, reach and impact of the communications.

In the screenshot, you might have also seen the use of direct messages with delivery confirmations. I will cover that in a future post, as it is another complex and fascinating topic of possibilities!



Hacking on a basic Bluetooth mesh-y concept

Inspired and frustrated by the closed, murky, proprietary nature of FireChat, and equally frustrated by my experiencing working on the way too complicated Commotion mesh project, I wanted to find a simple way to answer the question “what do we do when the Internet goes away” problem. FireChat is clearly not the answer for the types of communities I am trying to help, but in its absence, we have no other solutions, it seems.

What I have discovered is that Bluetooth device names (the things  you see when you are trying to pair a bluetooth device to your phone for instance) are actually a really great way to broadcast messages from your phone or computer to anyone within distance. This was partly inspired by the humorous wifi SSID messages that people often use, but the key difference is that Bluetooth device names can actually be 248 bytes long (80-240 letters/glyphs depending upon unicode language), as opposed to the much shorter ~30 character wifi SSIDs. It is also very easy to dynamically change your Bluetooth device name through open programming APIs.

The idea then is to use your device’s Bluetooth name as a kind of Twitter status message bearer, sharing key information during a crisis or as an act of protest/speech. It doesn’t require an app, just a little bit of knowledge and a new behavior. I have built an app (more below) that makes the user experience much simpler, and adds the ability to support retweets/shares (to expand the radio mesh reach), verification, privacy and even encryption (in theory).

To test the basic premise however, if you have an iPhone or iPad, you can set your device name in the general about settings. Then go to the Bluetooth settings area, and you will see all devices that are currently broadcasting. With Android, go to the Settings->Bluetooth screen, and you can “rename phone” from the menu, and set the visibility and timeout of your broadcast. With iPhones, as long as you stay on the Bluetooth screen, it will broadcast. With many new Android phones, you can set your visibility/broadcast timeout to 1 hour or infinite.

You can set a message like “!Gather 7pm at 1st and Main” or “@press please don’t photo faces” or “#Legal Aid is 2125551212”, or even just motivational messages “#staycalm #noviolence” or “#theworldiswatching”. If people like what you have written, they can change their status that message, and rebroadcast another 30 feet in whatever direction they are headed. Again, it is basically Twitter combined with doing “the wave” at a football game, except the wave is powered by these little super computers+radio stations we have in our pockets.

The Gilga app I am working on makes this all feel much more like a chat or Twitter type experience. The app also supports direct messaging using a secured RF socket. The important thing is that there a baseline concept here, that can be tapped into by anyone with a bluetooth device, be it a smartphone, an old Nokia, a PC with a huge Bluetooth antenna etc.

From a threat modeling perspective, there are risks about Bluetooth device IDs being scanned and logged, impersonation attacks based on modified Bluetooth radios, and the same misinformation spreading we see whenever we have an open commons, be it FireChat or Twitter. We have some ways to combat that, but it will be hard. My hope is that, by doing this work in the open, and with contributions by brilliant minds like yours, we can come up with some additional breakthroughs.


Gilga Meshenger: Messaging in the Bluetooth Babylon!

Some notes on the implementation, aka the glorious hack of Bluetooth Device Names. This application was original based on the Android SDK BluetoothChat sample. It used insecure (unpaired) and secure (paired) Bluetooth RFComm sockets to allow for short messages to be sent between devices. The primary modification that this project has made has been to add support for a “Broadcast” mode, that uses the Bluetooth device name, that is public visible during the Discovery process, as the message transport itself.

The design goals of this project are:

  • A truly decentralised application that requires only Bluetooth connectivity and has no central user registry
  • Incredible ease of use that ensures all “mesh” connectivity happens with as little user involvment as possible
  • Ability to enable trust or reputation for specific users or devices you message with
  • A very transient app that stores no data permanently
  • Ability to share the app easily between devices
  • A “fire and forget” mode, where the user can enter a message, put the phone in their pocket, and walk around and area and have it broadcast to all devices it encounters

alt   alt

The key innovations/hacks/revelations that led us to this point were:

  • As of recent Android versions, you can call an API to set your the device’s Bluetooth visibility to a very long time ~1 hour
  • You can dynamically change the Bluetooth device name, and it can be long – up to 248 bytes encoded as UTF-8
  • That the first two things above could be wrapped mostly in API calls the user did not have to see or worry about

Finally, some thoughts on security, privacy and reputation:

  • This app supports both a public broadcast mode, and a private, direct message mode. It is easy to use to both. The direct message mode is optionally secured and encrypted at the Bluetooth level if you have paired with the device/user you are connected with.
  • Impersonation is combatted by simplified user id’s to a short (6 character alphanumeric) value, based on the device’s unique Bluetooth ID. This makes them speakable and easy to remember. If someone says “trust messages from A1BC99” then likely you will be able to rememember that.
  • If you pair with a user (using standard Bluetooth pairing settings), their userid will be appended with a *, to make it even easier to know this is someone you should trust
  • The app ONLY works in Bluetooth mode, so though is no confusion when it might be using 3G/4G, Wifi or some other mode, and possibly go through a centralised server
  • The code is open-source, very small, and the entire app is only 28kb making it easy to audit, test and share
  • We make it easy to “retweet” a message by long pressing on it, which enables reputation for something to be built up by multiple people resharing it. If the user has paired with the user, you will also see the * next to the name to further indicate trust.

My raw thoughts on Google’s acquisition of Motorola Mobility

Overall, I am positive on the acquisition, with my main concern being that Google is clear and decisive about how they plan to proceed with the integration and operational side, and that they don’t unintentionally create confusion and concern in the consumer market.

Obviously this acquisition is related to the ongoing patent wars between Apple and Google (with their hardware partners HTC and Samsung as the primary proxies for litigation). Motorola has a deep, broad collection of intellectual property. Not only did they invent the cellular telephone and have years of creating popular consumer mobile hardware (StarTAC!), but they also have created their own Linux+Java mobile OSes in the past, which could provide support for Google in the case vs. Oracle.

I don’t think this will change much for developers in the next few years, as Android has great momentum that won’t end anytime soon. It may be a boon ultimately, as Google must work harder to maintain the image of Android being open now. The more transparency and code they release, the better for all.  I would also hope Google uses this to support and/or indemnify its app developers from worrying about being sued by patent trolls like LodSys.

Motorola has a “Pro” category of devices, with enhanced security in the OS to meet enterprise and gov requirements, as well as Blackberry style keyboards. This device could be a “Nexus Pro” sold bundled with Google Enterprise services to take on RIM directly as complete business tack. Google is having a lot more success in this space than people realize, taking on IBM, Microsoft and RIM all in one swoop. This is an area that Apple cannot compete in.

It will be a tricky task to manage Android and Motorola business units of Google. While not entirely comparable, there are some good lessons to learn from Palm and Apple’s own failed attempts at licensing an OS while producing their own competitive hardware. I was at Palm when we had the PalmOne (Hardware) and PalmSource (OS) divisions, when there were still Palm licensees such as Handspring and Sony, and it was a really difficult mess. PalmSource had to treat us like a separate company, in order to appease partners, but at the same time, we didn’t have the freedom those partners would have to implement their solutions because we had to maintain unity with the Palm vision. Eventually, all the licensing ended, Palm bought Handspring, and the whole company unified again, and then ultimately failed, and was acquired by HP.

Discussing New Tactics for Human Rights

This week, I’m participating in a one week online dialog regarding the development of new tools and tactics for the purpose of documenting human rights violations. The New Tactics in Human Rights Project, led by a diverse group of partner international organizations, advisors and practitioners, promotes tactical innovation and strategic thinking within the international human rights community. While there is an amazing list of researchers and practitioners who have been invited to seed the thread, all are welcome to join in the discussion, as well.

Here’s a brief summary of what we’ll be covering:

Join us for this important on-line dialogue featuring Documenting Violations: Choosing the Right Approach from January 27 to February 2, 2010. This dialogue will feature practitioners that have developed database systems to document human rights violations, organizations on the ground documenting violations, and those that are training practitioners on how to choose the right approach and system for their documentation. We will look at options for ways to collect, store and share your human rights data safely and effectively. If you are trying to figure out the best documenting system for your work – or if you have found something that works well, please join us for this conversation to share your questions, ideas, resources and stories!

Featured Resource Practitioners
Featured resource practitioners for this dialogue include (click here for more biographical info):

  • Vijaya Tripathi and Megan Price work with the Martus database developed by Benetech
  • Agnethe Olesen, Daniel D’Esposito and Bert Verstappen work on the OpenEvSys database developed by HURIDOCS
  • Jorge Villagran and Sofia Espinosa of the Guatemalan National Police Archive Team
  • Patrick J. Pierce, head of the International Center for Translational Justice – Burma Program
  • Oleg Burlaca, utilizes HURIDOCS methodology and working on websites for World Organisation Against Torture and SOVA Center for Information and Analysis
  • Patrick Stawski, Human Rights Archivist at Duke University and Seth Shaw, Duke’s Libraries’ Electronic Records Archivist
  • Jana Asher, M.S., is the Executive Director of StatAid
  • Agnieszka Raczynska of Red Nacional de Organismos Civiles de Derechos Humanos, Mexico
  • Daniel Rothenberg is the Managing Director of International Projects at the International Human Rights Law Institute (IHRLI) at DePaul University College of Law

Read on:

The Droid's Dharma: Supporting the Tibetan Language on Android

DISCLAIMER: I am by no means an expert in this issue – I am just an an enthusiastic hacker with a dream. Also I don’t read Tibetan, but I enjoy looking at it!

Thanks to the open-source movement and the hard work of many Tibet supporters and typography experts, I am happy to announce that  rendering of Tibetan characters is now supported on the most fantastic of mobile smartphones, Google Android!!!

Tendor’s Yarlung Raging blog viewed on a T-Mobile myTouch3G Android Phone

While it only has a small alphabet of characters, the Tibetan language has been notoriously difficult to support on Mac, Windows and Linux due to some complexities in how one character can modify the next. Dedicated academics, volunteers and software engineers have stayed focused on solving this and the most recent versions of all major operating systems are able to render Tibetan and provide Tibetan character input tools. Google Android is based on Linux, and fortunately is able to support the use of the GPL-licensed Tibet Machine Unicode font.


However, by default Android only has a small number of fonts built-in, and doesn’t support the easy addition of new fonts or locales. It does however have something called the “fallback” font, which is used to render any encoded text it comes across that it doesn’t quite know what to do with.

What I realized is that you could replace this font with a Tibetan unicode font compatible with Linux, and that this would then enable Tibetan support in all applications on Android, including the web browser, email apps, instant messaging, and short messaging (SMS), among others.

The steps below outline the technical how to for Android users.

WARNING: This is not for novices. However, it isn’t rocket science either. Your average neighborhood mobile phone enthusiast should be able to figure out how to do this, and potentially help their friends do it too. Down the road, I hope we can make this process easier and/or Google will allow for the addition of any font to the system.

Step 1: Get Root on your Android device. You don’t need to mod your phone with a custom firmware, you just need root access to change system fonts. Here’s some places to start looking on how to (this changes weekly, btw, and differs for each type of Android phone):

Step 2: Download Tibet Machine Unicode font. You can learn more about the variety of Tibetan fonts available here.

Step 3: Make the system font folder writeable and backup the existing font
This can be done using desktop ‘adb’ tool from the SDK or the Android terminal app on the device

# su
# mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
# chmod 777 /system/fonts
# cd /system/fonts
# mv DroidSansFallback.ttf DroidSansFallback.ttf.bak
# exit

Step 4: Write the Tibetan unicode font as the new fallback font:
Using ADB Desktop tool with Android connected via USB

adb push TibMachUni-1.901b.ttf /system/fonts/DroidSansFallback.ttf

Using on-device terminal app:

#cd /system/fonts
#wget -o DroidSansFallback.ttf /system/fonts/DroidSansFallback.ttf

Step 5: Reboot your Android phone

Step 6: Point your Android browser at, or to verify the Tibetan font support is properly installed.

What’s Next

Two big steps from here… this is a call to action for Android developers out there:

  • Develop a one-click app that can install Tibetan (or any other third-party language) font for any rooted device
  • Port an existing Java-based Tibetan input utility into Android as an Input Method Editor so that you can have a way to write Tibetan character emails, SMS messages and blog posts.

Many thanks to the authors and developer behind the following posts upon whose work this effort was based: How to change fonts in Android? Mounting /system partition in read-write mode in Android Adding Additional Language Fonts to Android