ChatterBox and Meshstastic seem quite similar on the surface, but other than the fact that they both use LoRa (as do many other systems), they are actually quite different. If you notice any misstatements regarding meshastic here, please contact us so we can make double-check our facts and make corrections. Since both are changing rapidly, information that was up to date here at the time of writing could be deprecated.
I think the main differences that stand out for ChatterBox are the ease of use and non-phone UI. Beyond that, there is also the unpredictable frequency hopping, automatic asymmetric encryption, mesh-wide location/connectivity awareness, distributed mesh cache, signed delivery confirmation, zero dependency on phones or apps, broadcast deliveries automatically propagate for up to 24 hours, remote control features, proximity sensor integration, thermal cam integration, and more.
 |  |
 |  |
| ChatterBox | Meshtastic | |
|---|---|---|
| Learning Curve Is it hard to setup and use? | Easy to set up and use. You should be able to hand devices out to your friends/family, and they will intuitively figure out how to use ChatterBox, without understanding frequencies, installing apps, entering keys, or any other tech setup. Setting up a new device is essentially powering it on and going through a few steps at startup. | Requires both device (node) setup and app installation/setup. Some or most of this will need to be repeated for every new device/person that wants to use it. Users will need to become somewhat familiar with RF, LoRa, app settings, and the device(s) they plan to use. Source |
| Privacy vs Openness Is it more community oriented or private? | Designed primarily for private comms & location. Prioritizes privacy above openness at all levels. | Open Source and more community oriented. |
| Mesh Awareness Does each device keep an evolving knowledge of other devices? | The cluster as a whole has shared state/knowledge. This knowledge constantly evolves and is stored in a decentralized way across all devices. Open Channels mode allows encrypted, frequency hopping, symmetrically encrytped/signed communication outside the scope of a cluster (unlimited devices), but many advanced features of clusters are not available with channels. Each device in your cluster is aware of the cluster’s state at any given time. Every device in the cluster knows which devices are connected, where a device is positioned (for devices with secure location sharing enabled), and which devices are within range of one another. In other words, the state of your cluster and all devices within it are privately known to all device within your cluster. | No such concept |
| Mobile Phone / App Integration Is the technology centered around mobile phones and potentially-compromised devices? | Designed to be completely independent from phones, apps, and modern OS’s in every possible way. This was a very high priority in the design of ChatterBox. We have ported the ChatterBox library (C++ code) into a proof-of-concept Android app in mere days, with no trouble, but are hesitant to offer an “app” because we don’t want to: 1. Be at the whim of app stores, wagged around by their absurd dictates 2. Have your data anywhere near an OS that’s likely spying on you, using the device and bandwidth you pay for (wtf??) 3. Enable a false sense of security, when modern OS’ likely have a per-device kill switch or per-app kill switch that can shut down any phone or app at any time | Heavily dependent on meshtastic app, mobile phones, and modern OS. |
| Distributed Mesh Cache Decentralized/encrypted cluster-wide storage | When a message is sent to an out-of-range device, the asymmetrically encrypted packets are stored in the distributed mesh cache. This is essentially encrypted/shared storage, where each device has a certain amount of storage allocated. It’s each device’s responsibility to trickle packets closer to the intended recipient, until final delivery is confirmed (and digitally signed) by the recipient. At that time, the packets for that recipient are wiped from the mesh cache across all devices. | No such concept |
| Live Mesh Graph Evolving knowledge of past and current connectivity of all devices within the cluster | Knowledge of connectivity (as well as past connectivity) and GNSS location is shared throughout the cluster automatically and all the time. This helps devices plan smart paths for routing packets to out-of-range devices. It also helps if you are using ChatterBox devices to navigate to other people or nodes in your cluster. | No such concept |
| Symmetric Encryption Encrypting using a common/shared key | Each cluster has 4, private to the cluster, symmetric keys. These keys are used for broadcasting encrypted messages, encrypted location sharing, propagating cluster health/connectivity, and determining the cluster’s frequency at any given time. | Can be configured to use AES256-CTR symmetric key encryption or not. A default-supplied key effectively starts everyone with the same encryption key, but users can change this. Source |
| Asymmetric Encryption Encrypting using public/private keypairs, only known to sender & recipient | All communication between two devices in your cluster are asymmetrically encrypted, meaning no other devices (whether in your cluster or not) can decrypt. Even devices in your cluster that store these packets in their cache cannot decrypt. Public keys for devices are automatically propagated throughout the cluster as new devices are added. Any device can prove its public key is legitimate, when challenged, by providing a root-signed certificate that authenticates both the device alias and public key. | Asymmetric encryption can happen between two devices, provided they become within transmission range and have a chance to exchange public keys. It is unclear how one device can know for sure it’s receiving the correct public key during that exchange. Source |
| Digital Signatures Digital proof the message is unmodified and from the stated sender | All DMs, broadcast messages, pings…everything – is digitally signed. All messages have a signed expiry as well, so if messages were to be “replayed” later, they are ignored. ECDS is utilized for signatures. | Essentially the same answer as above. Digital signatures are supported under certain conditions. Source |
| Frequency Hopping Utilizing multiple frequencies, rather than a single one | Cluster changes frequency unpredictably for extra security and resistance to interference/jamming. When you set up your cluster, you can choose to enable frequency hopping (up to 64 channels). This is enabled by default. All devices in your cluster adjust the main frequency in unison, based on the settings of your cluster. The next frequency is impossible for anyone to predict, unless they have the cluster’s private symmetric keys. For delivery between 2 devices (meshing or DM), the frequency changes per packet and utilizing asymmetric keypairs. This means for any given message, the delivery will be spread across 3+ frequencies utilizing an unpredictable pattern. | No such concept |
| Mesh Algorithm How messages/packets are routed from a sender to a recipient | Utilizes a finely-tuned mesh routing algorithm that is able to predict the shortest path(s) and target deliveries utilizing those paths. This is made possible with the mesh graph, decentralized knowledge of the cluster’s state, and a set of carefully crafted mesh algorithms. | The first hop is broadcast to any device within listening range. The second hop might be able to be more directed, if some state has built up, if devices have not moved/disappeared, and maybe other caveats. For LoRa, all of this happens on a single frequency. |
| Delivery Confirmation Verifiable proof that the recipient has the message | Authenticated, reliable delivery confirmation, regardless of whether the message was delivered in one hop or 20 hops. Once the recipient’s device has received the message, a signed confirmation is returned. The sender will see a green (direct) or blue (mesh) check mark when that happens. That means you can be guaranteed the message is sitting on the recipient’s device. The confirmation cannot be faked. With broadcast messages, you will receive confirmation when at least one device has fully received/decrypted/validated your message and is actively forwarding it. This is shown as a green checkmark in the UI. | No reliable automatic delivery confirmation. An ACK packet is returned if something picks up your message, but the ACK could come from anywhere and is not signed. Source |
| Remote Commands / Sensors Can it control things and sense things? | This is where a lot of current and future effort in ChatterBox is being spent. See a summary of current mesh remote control capabilities. You can build a secure mesh-enabled remote switch or a mesh-enabled proximity sensing node right now with ChatterBox, quite easily. These devices have all the same security and mesh capabilities as any other node, including asymmetric encryption, digital signatures, frequency hopping, etc.  | Unknown |
| Beyond Messaging Can it do more than text messaging? | ChatterBox has been designed to work with non-text payloads, such as low-resolution images, thermal images, and other binary formats. As of ChatterBox firmware version 2.0, thermal images can be sent via Communicators (T-Deck) or nodes. We have easy-to-follow DIY ChatterBox T-Deck thermal camera instructions. These images are asymmetrically encrypted and digitally signed, and delivered via frequency striping, just like any other ChatterBox payload.  | Unknown |