Skip to main content

Competitors

By far one of the most common questions we face is "why not just use [insert protocol here]?" This page is dedicated to answering that question. We will compare our protocol to other protocols, and explain why we believe our protocol is the best choice for our use-case, and, importantly, why we need to build our own protocol in the first place. This is designed more as a reference for our team when answering questions, and isn't written thoroughly enough to be a public-facing document yet.

Why Not Just Use [Insert Protocol Here]?​

We get questions a lot about why we don't just use Meshtastic for our LoRa network, or why we don't use MQTT for everything, or why we don't use BLECON for BLE. The answer is that we want to be able to support all of these networks and more, and we want to be able to do it in a way that is secure, efficient, and scalable. We also want to be able to do it in a way that is flexible enough to handle changes in the future, like new networks, new devices, or new security vulnerabilities. We believe that our protocol is the best way to do that, and we are constantly working to improve it and make it better.

Meshtastic​

Fundamentally, Meshtastic is very similar to what we want to do. To best clarify the differences and why we are not using Meshtastic, we will list the pros and cons of Meshtastic:

Pros​

Specifically things that are different/better than our protocol:

  • Implemented, working, and deployed
  • Open Source
  • Security Audited
  • Various message types (tracking, chat, broadcast, telemetry, remote config, etc.)
  • Extensible with plugins (screens, GPIOs, etc.)
  • Onboard GPS option
  • Hardware to BLE/Wi-Fi/Mobile App/hardware working

Cons​

Things that are worse or different from our protocol:

  • No forward secrecy in encryption (public/private key pair with no rotation)
  • Key stored on hardware device (not mobile app like us)
  • Purely hop-based routing with 3 as default 7 as max
  • SNR-based time slotting (we do this + more)
  • Supports unencrypted messages
  • No channel hopping / FHSS
  • Manual channel selection and modem configuration (bandwidth, spreading factor, etc.)
  • MQTT public server doesn't allow hops (cannot relay from internet to LoRa)
  • Potential overhead for their specific use-cases unrelated to our own
  • No support for other networks (BLE, Sidewalk, etc.)
  • No support for internet routing
  • GPLv3 license (not compatible with our proprietary software)

BLECON​

Protocol for BLE to internet. Met with them, and not a great fit right now. They are more focused on BLE to internet, and we are more focused on BLE to BLE, BLE to LoRa, etc. They are also more focused on the IoT market, and we are more focused on the consumer market. We could potentially use BLECON for BLE to internet routing, but it would require a lot of work to integrate with our protocol.

Bridgefy​

This CBTM for us to use under the hood for BLE and Wi-Fi direct connections. Follow-up call with them to discuss potential integration. Appears to be ~$0.02 per MAU not on internet, but also some sort of revenue sharing? Unclear about all this or how their stack works, should look into SDK implementation code. Also, iffy on their security and privacy practices especially historically, so maybe not great but do have a network.

Tox​

Matrix​

Matrix is a protocol for real-time communication. It is built on an open standard, so it is very flexible and extensible. Beeper is a good example of a service that uses Matrix to connect to other chat services. We could use Matrix to connect to other chat services as well, but it would require a lot of work to integrate with our protocol. Matrix isn't likely to be a good fit for our internet routing, as it assumes a stable internet connection and is not designed for intermittent or low-bandwidth connections.

Signal​

The Signal protocol is the basis for our encryption, but the Signal app itself cannot be used as it does not allow us to use our own networks or function offline.

Briar​

Mobile app for secure messaging over Bluetooth, Wi-Fi, Tor, etc. It is a good comparison to our protocol because it is also a secure messaging protocol that is designed to work across multiple networks. Here are the pros and cons of Briar:

Pros​

  • Very private
    • Subscribed tags are unique per message for each sender/recipient
  • Supports Tor (automatic based on location, can use with or without brides)
  • Supports Bluetooth, Wi-Fi, Tor, etc.
  • Mobile app (Android)
  • More than only messaging (groups, forums, blogs, etc.)
  • Open Source
  • Key rotation for forward secrecy
  • Supports framing
  • Seemingly medium agnostic (although not clear) so it could be extended to support other networks
  • No mesh network means flooding is less of an issue

Cons​

  • No specific built-in support for other mediums (LoRa, Sidewalk, etc.)
  • No iOS app (yet, but planned)
  • Must meet up in person to exchange keys via QR code
  • Unclear how to implement/integrate
  • Doesn't seem very "mesh" - you only connect to people you know over BLE, Wi-Fi, etc

Wesh / Berty​

P2P network over IPFS on OrbitDB. Fully decentralized, secure, and private. Here are the pros and cons of Wesh/Berty:

Pros​

  • Fully decentralized
    • IPFS for storage (supports non-internet connected networks, has support for internet connected networks and services like Cloudflare meaning we can have our own IPFS nodes that are internet connected and backup/redundant for network and help to sync etc.)
    • OrbitDB for database (supports offline-first, eventually consistent, and CRDTs)
  • Libp2p for networking (supports multiple transports like BLE, Wi-Fi, etc.)
  • Distributed w/ authentication and authorization meaning multiple devices can be used to access the same account
  • Built on gRPC / Protocol Buffers like us
  • Has an SDK/toolkit to build on top of with built-in encryption, identity management, network routing, etc. etc.
  • Uses symmetric ratchet for forward secrecy (HKDF)

Cons​

  • Written in Go (harder to integrate with our existing codebases and devices)
  • No real mesh network (only direct connections) - may be possible with Libp2p and something like gossipsub
  • IPFS is slow and not great for real-time messaging
  • IPFS is hard for mobile networks
  • IPFS is susceptible to Sybil attacks

Yggdrasil​

Mesh network over IPv6.

Unrelated IPFS discussion

Here are the pros and cons of Yggdrasil:

Pros​

  • Very open and flexible

Cons​

  • LGPL3 License (not compatible with our proprietary software)
  • Written in Go (harder to integrate with our existing codebases and devices)

SimpleX​

Pros​

  • No user IDs for best privacy

CJDNS​

GPL Licensed, can't be used in proprietary software. Mesh network over IPv6.