Category: Thali

Starting with Android Marshmallow (see here) it is no longer supposed to be possible for programs running on Android to see the local device’s Wi-Fi or Bluetooth MAC address. This is a major problem for Thali because we depend on retrieving the Bluetooth address and then advertising it over BLE. A peer device then connects using the Bluetooth MAC retrieved over BLE with an insecure RFCOMM connection and then they authenticate/encrypt the connection at the application layer. But now this method won’t work because as of Marshmallow we aren’t supposed to be able to get the Bluetooth MAC address. Below I explore the various avenues we are investigating to try and deal with this change. But if anyone knows anyone at Google we can talk to about this that would be really helpful.

We previously outlined the basic protocol exchange for identity exchange for Thali here. But implementing this protocol requires dealing with a lot of details. The purpose of this specification is to capture those protocol issues. This is not intended as a proper protocol specification. It is makes a number of assumptions that are unique to our implementation environment. Eventually, for interoperability purposes, we will need to generalize this spec, but not today.

Thali’s mission is to create an open source/open standard peer to peer web. This means both local peer to peer (e.g. you and I are standing next to each other, can our devices talk directly even if there is no Internet?) as well as remote peer to peer (e.g. you and I are both on the Internet but aren’t near each other). We have outlined a series of stories (or milestones or sprints or whatever your favorite term is) that lead us where we want to go. Today we released story 0 which contains almost all of the core technologies we need to make Thali fly! There is a ton of work to do but at least now we have a foundation to stand on.

As part of Thali we need to enable iOS and Android devices to communicate to each other just using local radios. For reasons explained below the only way we can figure out how to do this involves security issues and user intervention on the iOS side. If anyone has any better way to make this work I’m all ears!

As part of developing Thali we have a series of stories. One of our stories is -1 whose goal is to enable the native discovery and high bandwidth P2P frameworks we have on iOS and Android to successfully work with JXCore’s implementation of Node.js on those platforms. We originally had intended to start with story 0 but we have had enough challenges at the native layer that it made sense for us to just break out a simpler story using TCP/IP sockets rather than the full PouchDB stack as our first baby step. This article explains the simplification.

As part of the Thali project we are working on using BLE and Wi-Fi Direct to provide for local discovery. That is, the ability to discover who is around you using BLE/Bluetooth/Wi-Fi. This feature has enormous implications for people’s fundamental rights to privacy as well as personal security. So in this article I try to enumerate what rights I believe users of local presence software must have for such software to be considered ethical. I built these rights based on Kim Cameron’s Laws of Identity.

As part of Thali we are trying to enable people to easily build peer to peer apps on mobile devices using PouchDB. A problem we have run into is how to implement ACLs in a way that doesn’t cause developers writing on our platform to tear their hair out. I make a proposal below but I have to admit that I have no idea if it’s right or sensible. But I figure we have to start some place. What do you think? You can share your ideas on this blog or better yet, on Thali's mailing list!

Awhile back I ran an analysis to pick a backlog manager for Thali. My winner was Pivotal Tracker and I really like it. It’s super slick. But as an open source project we need to run our backlog out of our GitHub issues so we can manage everything in one place. While Pivotal Tracker has an add-on that provides GitHub issues integration, it’s clearly an afterthought. So I’m back to look at backlog managers that run straight out of GitHub. My winner this time is Waffle

Asking about a system’s performance is usually an invitation to a fight, not to useful data. But I did want some idea of how JXCore, a fork of node.js that runs on mobile OS’s, performed on iOS and Android. See here for more info on JXCore. Since the work I’m doing heavily involves PouchDB I decided to take the PouchDB performance tests and run them in six different environments and compare the results. Over all, one should expect node.js on a modern phone (Android or iOS) to be around 10x slower than on a PC. Which honestly, isn’t that bad when you think about it. I want to give a shout out to Brian Lambert for making the iOS tests happen and to Oguz Bastemur from Nubisa for helping us past various bugs. Oguz was very patient with Brian and I and we really appreciate it.

JXCore is a fork of Node.js that introduces multi-threading support and a Javascript engine abstraction layer to plug in different Javascript engines. They have support for iOS using Spidermonkey and Android using v8 and Spidermonkey. Below I provide a FAQ about who they are and what they can do.