Ask HN: How does firechat accomplish mesh networking?

It sounds pretty straightforward for WiFi: you have two devices connected to WiFi on the same network. These two devices can broadcast to let each other know that there is someone else there. After that, the IPs are known and devices can talk to each other. There is nothing platform specific in this model: standard UDP and TCP, nothing more than that.

I am not familiar with BT protocol so I can't comment on how it is done with BT.

I've researched this area and there are a few issues to be aware of. First of all, it's important to note that Android does not have the same built in "off the grid" networking that iOS recently introduced. So, as OpenGarden stated on Techcrunch, Android clients rely on some combination of Bluetooth and wifi.

Second of all, a common issue with implementing peer-to-peer networks is NAT traversal. Because the internet has more devices than it does IPv4 space, it's segmented into siloed networks (NATs), each with it's own IP space. So connecting two peers is nontrivial, because the public address of one might mean something totally different to another. To accomplish peer to peer tunneling, you need some kind of intermediary to coordinate the addressing. Because of that, many p2p applications require changes to router/firewall rules to solve the addressing problem. Obviously this is suboptimal, especially on mobile. But recently, Google has made a lot of strides in this area with it's technology underlying Google Talk and WebRTC. This tech, encapsulated in a library called libjingle, relies on the STUN and TURN protocols for intermediary servers to coordinate addressing between peers. For 92% of devices on the Internet, the STUN servers are able to coordinate addressing between peers without having to relay any of the data. For the other 8%, TURN servers sit in between the peers and relay data. This is the technology that enables Google Talk and WebRTC to be so scalable. When 92% of bandwidth can be offloaded to peers, there's much less of a need for central servers and bandwidth.

Now consider that any p2p IP tunnel can be opened between two devices connected to the Internet, using this STUN/TURN protocol via something like libjingle. (See socialvpn.org for an example.) This tunnel can be a generic transport, or it can act as a UDP proxy (I believe this is how Hola! Chrome extension works).

You now have the ability to create a p2p overlay network, with direct tunnels between peers, on top of any Internet or generic network of devices. The key component is libjingle along with STUN and TURN servers, which enable direct p2p addressing.

My hypothesis is that OpenGarden used some combination of all these technologies. I think the reason they're quiet about how they accomplished it is because, 1) Android probably doesn't work as well as iOS in sparse offline areas (not enough Bluetooth parity), and 2) they are relying to some extent on central servers, for the TURN/STUN protocol.

That's just my hypothesis, and I've never actually implemented anything with this technology, but rather have only read about it. If someone wants to correct me on any number of the points I'm sure I got wrong, please do.

I'm excited to know this exists. I've been watching the Serval Mesh project for awhile. https://play.google.com/store/apps/details?id=org.servalproj...

But it requires rooting your phone. This is very cool, and I hope it becomes ubiquitous, as a method of circumventing the grid, either because it's compromised or it's down, or it's just not present to begin with, is huge.

At first I thought along with others that they're probably relying on some combination of Bluetooth and Wifi. When I launch FireChat though, it tells me that to use the chatroom that does not require Internet, it only works "up to 210 feet." Well, that's interesting because Bluetooth LE should work up to over 300 feet. If we're talking about two users on the same WiFi, they should be able to chat for as far a distance as that WiFi network, which again should be greater than 210 feet, depending on the system. So, if they're using a combo of WiFi and Bluetooth, how do they end up with a shorter distance?