MOSA: Building a Mesh Communication Ecosystem Without Internet Infrastructure

MOSA development began in September 2024 and is ongoing. It's unlike anything else in our portfolio — not a web application, not a SaaS product in the conventional sense, but a full communication ecosystem engineered for environments where internet infrastructure either doesn't exist or can't be trusted.

The system spans three distinct layers: a Flutter mobile application, custom gateway hardware running on Zephyr RTOS and ESP-IDF, and a zero-knowledge PHP internet gateway for when connectivity is available. Each layer is designed to operate independently and degrade gracefully when adjacent layers aren't reachable.

The Problem with Assuming Connectivity

Modern secure messaging platforms — Signal, WhatsApp, enterprise tools like Slack — all route communication through central servers. This architecture has real advantages in normal conditions. It breaks completely when connectivity does.

The environments MOSA is built for make this failure mode a design constraint, not an edge case. Field operations in remote areas. Facilities where internet access is restricted or actively monitored. Situations where infrastructure is disrupted by physical events. In all of these, a communication system that depends on a central server stops working at exactly the moment it's needed most.

The Flutter Mobile Application

The user-facing layer is a Flutter application that handles encrypted messaging, voice calls, and location sharing. Flutter was chosen for a specific reason: a single codebase that compiles to native performance on both Android and iOS, with access to the low-level Bluetooth APIs required for BLE mesh participation.

The application manages the full communication lifecycle from the user's perspective: identity and key management, contact discovery within the local mesh, sending and receiving messages with delivery confirmation, initiating voice calls over the mesh, and sharing location data with selected contacts. All of this works without an internet connection when the device is within range of other MOSA devices or a gateway node.

The UI is designed for use in field conditions — high contrast, large touch targets, minimal navigation depth. The assumption is that users may be operating under stress, possibly with gloves, possibly in low light.

The BLE/LoRa Gateway: Zephyr RTOS and ESP-IDF

The gateway hardware is where MOSA becomes genuinely unusual. Physical gateway nodes bridge mobile devices to a wider mesh network using two radio technologies with complementary characteristics.

Bluetooth Low Energy (BLE) handles communication with nearby mobile devices. BLE has limited range — typically 10–100 metres depending on environment — but low power consumption and native support on every modern smartphone. Mobile devices connect to the nearest gateway over BLE without requiring any special hardware on the phone.

LoRa (Long Range) handles gateway-to-gateway communication. LoRa can reach kilometres in open terrain with low power requirements, making it viable for deployments where gateway nodes need to be placed far apart and run on battery power. The tradeoff is low bandwidth — LoRa is not suitable for voice traffic between gateways, but it's more than sufficient for text messages and location pings.

The gateway firmware is built on two complementary embedded frameworks. Zephyr RTOS provides the hardware abstraction layer, real-time scheduling, and the BLE stack. ESP-IDF (Espressif IoT Development Framework) provides the drivers and WiFi stack for gateways that also have internet uplink capability. The combination runs on ESP32-series microcontrollers, which are compact, widely available, and capable of running both BLE and WiFi radios simultaneously.

Gateway nodes form a mesh among themselves. A message originating on a mobile device travels over BLE to the nearest gateway, then hops across the LoRa mesh to reach a gateway near the destination device, then over BLE to the destination phone. The routing is decentralized — no single gateway is the "master" of the mesh. If a gateway fails, the mesh reconfigures around it.

The Zero-Knowledge PHP Internet Gateway

When internet connectivity is available, MOSA can route traffic through a PHP-based internet gateway — but this gateway is architecturally zero-knowledge. It cannot read the content of any communication it relays.

Zero-knowledge in this context means the gateway operates purely on encrypted payloads. It knows routing metadata — source identifier, destination identifier, message size, timestamp — but the actual message content, voice data, and location information arrive at the gateway already encrypted with the recipient's public key. The gateway has no key material that would allow decryption.

This is not just a policy choice — it's enforced by the architecture. The PHP gateway has no access to the encryption keys used by end devices. Even if the gateway server were compromised or subject to a legal order, the communications passing through it cannot be decrypted without the private keys held on individual devices.

The internet gateway extends MOSA's reach: when a LoRa mesh segment has an internet-connected node, messages can travel from that mesh segment across the internet to another mesh segment in a geographically distant location. The end-to-end encryption guarantee holds across the entire path.

Decentralized End-to-End Encryption

Across all three layers, the encryption model is the same: end-to-end, with keys held only on end devices. There is no central key server. There is no "MOSA backend" that could be compromised to access message history.

Key distribution happens within the mesh itself. When two devices establish contact for the first time, they exchange public keys over an authenticated channel. Subsequent messages are encrypted with the recipient's public key before leaving the sender's device. Gateway nodes and internet relays see only ciphertext.

Voice calls use an encrypted stream rather than stored messages, but the same model applies: the audio is encrypted on the calling device and decrypted only on the receiving device. Gateway nodes relay the encrypted stream without access to audio content.

Location sharing is opt-in and contact-specific. A user can share their location with selected contacts — the location data is encrypted for each recipient individually, so a gateway relaying the data cannot determine the sender's position.

Where MOSA Fits

MOSA is our most technically intensive project. It's more accurately described as a communication infrastructure product than a SaaS application — organizations deploy it on their own hardware to build secure communication networks independent of commercial internet infrastructure.

Development is ongoing. The mobile application, gateway firmware, and internet gateway are all in active development. We'll publish more technical detail as each layer matures. If you're evaluating solutions for secure offline-capable communication in field, industrial, or critical infrastructure contexts, we're interested in hearing about specific deployment requirements.