MeshTalk: Decentralized Off-Grid Messenger

MeshTalk is designed to be a lifeline when the internet goes down or is unavailable. Using only Bluetooth Low Energy, each phone becomes a node in a decentralized mesh network. Messages hop from device to device until they reach the intended recipient, using a store-and-forward mechanism. The app runs entirely offline—no SIM card, no Wi-Fi, no cloud servers. It's built for hikers, activists, humanitarian workers, or anyone who values digital sovereignty. The vision is a resilient communication layer that works anywhere, anytime, without external infrastructure.

Users can send text messages, images, and location pins within a local mesh. The routing protocol uses epidemic diffusion with bloom filters to minimize redundancy and conserve battery. All messages are end-to-end encrypted with a simple key exchange. The UI is minimal and functional, focusing on reliability over polish. MeshTalk is not a social network; it's a utility—like a digital walkie-talkie that works silently in the background.

In many parts of the world, internet access is unreliable, expensive, or monitored. During natural disasters, cellular towers often fail, cutting off communication. Even in cities, centralized messaging apps collect vast amounts of personal data. MeshTalk scratches the itch for a communication tool that is truly independent, private, and resilient—one that doesn't rely on any third-party infrastructure. It's for people who want to talk without asking for permission.

• Enable one-to-one and group text messaging over a BLE mesh with no internet or cloud
• Support sharing of small images (resized to <100KB) and GPS coordinates
• Achieve message delivery within 5 minutes for nodes within 3 hops
• End-to-end encryption with simple public-key exchange verified by QR scan
• Consume less than 5% of battery per hour when mesh is active
• Provide a simple UX that works without any setup or account creation
• Open-source the core protocol and client for community auditing

• NOT a replacement for internet-based messaging (e.g., WhatsApp)
• NOT supporting voice or video calls (latency too high)
• NOT providing message delivery guarantees (best-effort)
• NOT a social network or content sharing platform
• NOT a mesh network for file sharing or browsing the web
• NOT requiring any server or cloud back-end at any point

• Frontend: Flutter (cross-platform, fast UI, good BLE libraries)
• Bluetooth: Android BLE API (for scanning, advertising, GATT) and iOS CoreBluetooth
• Local Storage: SQLite with WAL mode for message persistence
• Encryption: NaCl/libsodium implementation for end-to-end encryption
• Protocol: Custom epidemic routing using Bloom filters for duplicate detection
• Serialization: Protocol Buffers for efficient over-the-air message format
• Testing: Simulated mesh using multiple emulators with virtual BLE

MeshTalk operates as a fully decentralized peer-to-peer mesh. Each device runs a background service that periodically advertises its presence and scans for neighbors. When two devices come into BLE range, they establish a GATT connection and exchange a list of message hashes they have. If a device has a message the other hasn't seen, it pushes the full message. Messages are stored locally in an SQLite database with a status field (pending, delivered, seen). The routing protocol uses an epidemic (gossip) approach: each message has a time-to-live (TTL) in number of hops. When a message is received, it is stored and then forwarded to all new neighbors, except the one that sent it. Bloom filters are exchanged to avoid sending already-seen messages. The encryption layer ensures only the intended recipient can decrypt the payload using their private key. The app does not rely on any centralized coordination—every node is equal. To bootstrap the mesh, a user can create a temporary 'channel' with a shared secret that acts as a virtual room.

• BLE range is limited (~10m) requiring dense node coverage for network connectivity
• Battery drain can be significant if scanning/advertising is not optimized
• Message delivery is unreliable; messages may be lost if no path exists
• iOS BLE background limitations may reduce effectiveness on iPhones
• Spam or malicious nodes could flood the mesh (mitigation via reputation or proof-of-work)
• Adoption requires a critical mass of users; a single user is useless

• How to handle message delivery confirmation without a central server? (e.g., ACK piggybacking on forward)
• What is the optimal TTL value to balance reach and network congestion?
• Should we support multiple message priority levels (e.g., emergency vs casual)?
• How to prevent spam in an open, anonymous mesh? (e.g., small PoW per message)
• How to interoperate with existing mesh projects like Briar or Bridgefy?

The idea stayed a plan because after initial prototyping, it became clear that the app would only be useful if a community actively used it. Without a killer use case or a funded deployment (e.g., NGO partnership), the project lost momentum. Life moved on, and the developer shifted focus to a more straightforward offline-first app. But the concept still excites people when described.

This plan was originally sketched in 2022 after a workshop on disaster communication. The codebase started as a Flutter project but never got past the first milestone. The routing algorithm was simulated in Python, showing 80% delivery within 3 hops in a 50-node random walk scenario. A prototype on Android managed to send a 'hello' between two phones. The rest remained in design docs.