Mesh Capabilities

The Chatters platform offers some interesting and cutting-edge mesh delivery capabilities. The ChatterBox uses various techniques to get your messages where they need to go, securely, and as quickly as possible, without relying on the same possible-points-of-failure (or privacy invasion) of many other messaging systems. I won’t go into too much technical detail of how this is accomplished, but here are the basics. At the heart of the Chatter platform’s delivery system is the distributed mesh cache.

Distributed Mesh Cache

All Chatters devices have a certain amount of storage space (FRAM) reserved for holding encrypted packets of other trusted devices. Only the original sender and final recipient are able to decrypt the message, but intermediary devices are able to see where the message (packets) are supposed to go. These “meshed” packets will be stored across multiple devices within the cluster, and will trickle their way to the final destination as opportunities present themselves.

Ideal Scenario - Instant / Direct Delivery

“Person A” sends a message to “Person B,” who is in range with a powered-on ChatterBox. The message is encrypted, signed, transmitted over LoRa, received, decrypted, validated, and acknowledged. All this happens in about 1 or 2 seconds, after which both devices show the message, along with a check mark showing the message was definitely received. The message was encrypted using asymmetric keys of Person A and Person B, so no other devices (even trusted devices) in the area are able to read the message. No meshing is involved.

Mesh Delivery - Nearly Instant

“Some Sensor” needs to send data to “Hikers”, who are out of range. However, the Hikers do have their ChatterBox powered on. In this case, Some Sensor attempts instant delivery, but it fails. After a few seconds, Some Sensor instead puts the encrypted message into the mesh cache. The message is forwarded to whoever is in range, if they are capable of getting the message closer to the Hikers. Person B has his ChatterBox powered on, so it is targeted as the next hop. Person B’s device repeats the process, getting the packets to “Guy with big antenna”. Finally, the antenna guy’s massive boosted antenna is able to see the Hikers are within its range, so the message is delivered. The Hikers’ device receives/decrypts/etc, and then sends an acknowledgement (also via mesh). After a minute or so from the original send, the sensor has confirmation that the Hikers received its data.

Mesh Delivery - Delayed

In this case, the tricky part isn’t necessarily the distance, but rather that the Hikers want to send a message to “Gray Man” who only comes within range occasionally. In this case, the Hikers’ message is routed to the guy with big antenna. The big antenna device will decide if it should hold onto the message for Gray Man, forward it along another path, or both. Whenever Gray Man’s device does come within range (maybe hours later), the message will be delivered, and the Hikers will receive confirmation.

Mesh Smart Routing

If you are technically savvy, you may rightly be wondering, in the absence of any centralized service and on these small OS-less devices, how does a sending device know how to route a message to one far across the mesh “graph” to a device it’s never even been within two hops of before. That is a very difficult problem, if you stop and think about it. I won’t go too far into detail yet, but each device keeps a representation of what it thinks the mesh device graph looks like, and consults that graph to do path planning. This view of the mesh graph does not have to be perfect, or even close to perfect. The graph is populated by the “mesh quality” rating you may see on screenshots, and that rating becomes the heuristic for finding ideal paths. Also, any device along the way can re-route the message, based on newer information it may have. As the packets get closer to the final destination, the picture of the mesh graph near the final recipient becomes clearer and more accurate, so delivery can be completed, even if the originating device has zero knowledge of the far device.