Author: Administrator

I went to SF to meet with folks from the city of SF to discuss how we could use Thali to help improve recovery after a major earthquake. The meeting was both productive and eye opening. Our next steps are to put together a proof of concept to hopefully use in a live trial later this year. Below is an explanation of the who, the what, the why and most interesting as a geek, the how. Technologies and emergencies don’t necessarily mix so we have to think hard about how to make things better, not worse.

A big part of the Thali Project is running Node.js directly on “edge devices” like embedded hardware, phones, tablets, laptops, etc. I recently got asked why anyone would want to do this. My short answer is - P2P.

As I’ve previously discussed I want to get node.js running on Android, iOS and WinRT. But to make that happen we need to understand the node.js ecosystem and that includes native add-ons and node-gyp. So I created a node package, node-gyp-counter, to heuristically determine how frequent node-gyp usage is in the node.js world. If my numbers are right then less than 2% of downloads of packages in 4/2016 involved node-gyp in any way. Of that 2%, just 10 packages account for 76% of node-gyp root package downloads and only 5 of those are relevant to mobile.

[Updated with figures from 5/24/2016]

Twice in the last week or so I’ve had people ask me about using WebRTC with Thali. I’ve already addressed WebRTC and Thali here. But recently Dominique Legault pointed me at a very cool project, freedom.js, that both explains why people keep bringing up WebRTC and helps us to really understand the question of - what is a peer to peer web and why does WebRTC in the browser not create it?

Node doesn’t really have an application model in the normal sense since Node sees itself as a server technology. But as Electron, NWJS, JXcore and JXcore-Cordova have shown there is a real need for Node based applications, both on desktop and mobile. This article is intended mostly as a primer to explore some of the issues anyone wanting to jump into building applications that embed Node.js need to think about. [Note: Updated on 4/18/2017 to add Termux, thanks to Jean-Jacques Debray for pointing it out.]

Google in Android release Marshmallow prevents applications from seeing their device’s local Bluetooth or WiFi MAC addresses. This puts a big roadblock in front of peer to peer apps. There is a really obvious solution which I suspect Google has thought about, so now the question is - why haven’t they implemented it? Does anyone have a contact at Google I can talk to about this?

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!