MeshRelay

Entry Page(Bluetooth connection)
Onboading page
HomePage
Emergency Alerts page
QR Code page
Direct Messaging page
Settings page

Inspiration

MeshRelay was inspired by the reality that communication is often the first thing to disappear during blackouts, censorship, disasters, or conflict. In those situations, people may still be physically near one another, but they lose the digital infrastructure that normally keeps information moving. The project was built around the idea that devices can still act as local nodes, people can act as carriers, and information can survive by moving in small hops instead of depending on a central server. That matches the DTN / store-and-forward model in your spec, which is designed for disconnected and hostile environments.

The deeper motivation was to build something that feels practical, privacy-first, and resilient: a system where critical updates, alerts, and direct messages can still circulate even when the internet is completely unavailable. MeshRelay’s design goals explicitly focus on decentralization, privacy, resilience, cross-platform support, and low-bandwidth operation, especially under BLE-sized constraints.

What it does

MeshRelay is an offline-first cross-platform mesh communication app that lets users create, share, relay, and receive messages without relying on internet infrastructure. It supports public news-style updates, emergency alerts, direct messages, voice notes, QR-based communal message boards, and local peer discovery through BLE, Nearby Connections, WebRTC, and QR transport. The system uses message TTL, hop limits, deduplication, fragmentation, and relay logic so information can move across multiple devices in a controlled way.

At a functional level, it acts like a local survival communication layer: one device can create a message, another can receive and forward it, and a third can still access it later. It also includes privacy and safety features such as ephemeral identities, encrypted direct messages, local-only storage, and emergency wipe. The spec shows that the app is organized around Feed, DM, QR, Voice, Settings, and Connections screens, with all local state managed through Zustand and persisted in IndexedDB or session storage as appropriate.

How we built it

We built MeshRelay as a React 19 + TypeScript + Vite application, wrapped for native deployment with Capacitor. The app uses Tailwind CSS for styling, Zustand for state management, and IndexedDB for persistent local storage. The architecture is separated into presentation, state management, service, and transport layers so the UI stays clean while the networking, routing, cryptography, and storage logic remain modular.

The message pipeline is designed around compress, encrypt, fragment, transmit, and relay. Crypto is handled with AES-256-GCM, ECDH, ECDSA, and SHA-256. Transport is abstracted across BLE, Nearby Connections, WebRTC, and QR. The storage layer keeps messages, peers, fragments, relay queues, and deduplication data locally in IndexedDB, while the message processor enforces TTL, max hops, and relay decisions.

Challenges we ran into

One major challenge was designing for environments where connectivity is intermittent or completely absent. That forced us to avoid assumptions that normal apps depend on, like constant connectivity, always-on delivery, or centralized synchronization. The system had to work with limited bandwidth, low MTU sizes, and devices that may not always stay connected long enough for a full exchange. Another challenge was balancing privacy with usability. The spec intentionally avoids persistent identities, stores data locally, encrypts direct messages, and supports emergency wipe, but those protections also make design and debugging harder. Supporting multiple transports across web and Android also adds complexity because browser BLE, native Nearby Connections, QR scanning, and WebRTC all behave differently across platforms.

Accomplishments that we're proud of

We’re especially proud that MeshRelay is not just a concept, but a full modular system with real architectural depth. The project includes multiple screens, services, stores, transport layers, and detailed protocol definitions, all organized into a coherent offline-first architecture. The spec documents around 43 TypeScript/TSX files, 8 screen components, 12 service modules, and 3 Zustand stores, which shows that the project has already grown into a substantial working foundation.

We’re also proud of the privacy and resilience model. The use of ephemeral session IDs, encrypted transport, local-only persistence, deduplication, TTL-based expiry, fragmentation, and emergency wipe makes the system feel realistic for a blackout scenario instead of just being a messaging demo. The combination of QR boards, direct messaging, mesh routing, and cross-platform support gives the project a strong technical and presentation story.

What we learned

We learned that building for offline and hostile environments requires a completely different mindset from building normal apps. The hardest part is not just sending data — it is deciding how little data to send, how long to keep it, how to protect it, and how to make it useful even when the network is unreliable. That is why the project relies so much on compact packet design, fragmentation, deduplication, and hop-limited relay.

We also learned that cross-platform mesh communication is a layered problem. QR is universally reliable, WebRTC can help for local peer exchange, BLE is constrained by platform support, and native Android mesh capabilities add more power but also more complexity. MeshRelay taught us how to combine these transport options under one architecture without making the system depend on any single path.

What's next for MeshRelay

Next, MeshRelay can evolve in three strong directions. First, the offline web side can become more complete with a proper service worker, better caching, and installable PWA behavior. Second, the transport layer can be strengthened with more reliable peer discovery, better WebRTC signaling, and deeper Android mesh support. Third, the security model can be improved with stronger forward secrecy, more robust message authenticity, and additional protections against traffic leakage and abuse.

Beyond that, the product can grow into a richer resilience platform with better delivery confirmation, smarter routing, improved UX polish, accessibility, and potentially more advanced communication modes. The current spec already leaves room for future work such as stronger PWA support, better Bluetooth behavior, testing, and more polished mobile-native features.