ResQMesh

ResQMesh is an offline-first community incident-coordination network for the first hours of a disaster, helping people share SOS alerts, hazards, and resources during events like Nepal’s floods.

Comment

Inspiration

During disasters such as floods, earthquakes, landslides, and cyclones, communication infrastructure can fail precisely when people need it most. Cellular towers may lose power or become congested, internet connectivity can disappear, and responders can be overwhelmed by fragmented or duplicate reports.

We were inspired by a simple question: What if nearby phones could help keep critical information moving even when traditional communication infrastructure is unavailable?

ResQMesh was designed around this idea — creating an offline-first coordination layer that can connect communities, preserve incident reports, and help responders build a clearer picture of what is happening on the ground.

What it does

ResQMesh allows people to create structured Emergency, Hazard, Resource, Safe Route, and Status updates.

Each report can contain a unique ID, timestamp, expiry information, and — when explicitly enabled — last-known location information. In the intended production architecture, reports can move from phone to phone through a store-and-forward mesh, eventually reaching an authorised responder gateway.

The platform also provides explainable AI-assisted triage, identifying signals such as medical, trapped, flood, or blocked to assign a priority and suggest a next action. Human responders remain responsible for verification and action.

The current hackathon prototype demonstrates this coordination experience through a mobile-first PWA, a two-phone live demonstration, a lightweight Node.js hub, offline caching, and local AI-based triage.

How we built it

The hackathon prototype was built as a lightweight Progressive Web App using:

  • HTML5, CSS3 and vanilla JavaScript for the frontend
  • Service Worker caching for the offline application shell
  • Node.js with REST endpoints for live demonstration sync
  • In-memory server state and browser cache for demo data
  • A transparent, rule-based AI triage system for explainable prioritisation

For the prototype demonstration, two phones communicate through a laptop running the Node.js hub over the same Wi-Fi network.

Our intended production architecture goes further, replacing the laptop dependency with Bluetooth Low Energy discovery, Wi-Fi Direct/Wi-Fi Aware, encrypted store-and-forward routing, encrypted local storage, trusted gateways, offline maps, and human-supervised multilingual AI.

Challenges we ran into

One of the biggest challenges was balancing the hackathon prototype with the realities of disaster communication.

A true mesh network requires device-to-device connectivity, background operation, secure identity, encryption, message deduplication, expiry, hop limits, and reliable store-and-forward behaviour. These capabilities also differ significantly between mobile platforms.

We therefore had to clearly separate what could be demonstrated within the hackathon from what would be required for a production-ready emergency system.

Another challenge was designing AI responsibly. Emergency reports can be incomplete, ambiguous, multilingual, or duplicated. Instead of treating AI as an autonomous decision-maker, we designed the prototype to show why a report received a particular priority and keep final decisions with human responders.

Accomplishments that we're proud of

  • Built a working two-phone disaster coordination prototype.
  • Demonstrated real-time sharing of hazard and SOS reports.
  • Created an explainable AI triage layer that shows priority, signals, and recommended next actions.
  • Designed an architecture that can evolve from a laptop-based prototype into a device-to-device, store-and-forward mesh network.
  • Incorporated privacy and safety considerations from the beginning, including explicit location consent, message expiry, authorised responders, and human verification.
  • Designed a clear path toward using BLE, Wi-Fi Direct/Wi-Fi Aware, encrypted local storage, trusted gateways, and offline maps in the production version.

What we learned

We learned that building technology for disaster scenarios is not just about making communication possible — it is about making information reliable, explainable, secure, and actionable.

We also learned the importance of designing for failure. A disaster system cannot assume that internet connectivity, a central server, GPS, or even a single communication path will always be available.

Most importantly, we learned to treat AI as a decision-support tool rather than a replacement for human responders. A production system would require multilingual evaluation, bias monitoring, confidence thresholds, privacy safeguards, auditing, and mandatory human review.

What's next for ResQMesh

Our next step is to move from the coordination prototype toward a true offline, peer-to-peer disaster communication system.

The roadmap includes:

  1. Migrating the PWA to a native Flutter application with platform-specific networking capabilities.
  2. Implementing encrypted local storage and signed incident packets.
  3. Building BLE-based discovery and Wi-Fi Direct/Wi-Fi Aware communication where supported.
  4. Implementing robust store-and-forward routing with deduplication, expiry, hop limits, and delivery receipts.
  5. Adding explicit, encrypted and time-limited last-known location sharing for SOS reports.
  6. Expanding AI support to multilingual reporting, duplicate detection, and human-supervised triage.
  7. Testing the system through controlled disaster-response simulations.
  8. Working with disaster-management organisations to define responder gateways, escalation procedures, privacy controls, and operational requirements.
  9. Completing independent security, accessibility, reliability, and disaster-safety validation before any real-world deployment.

The long-term vision: when traditional communication infrastructure goes down, ResQMesh should help communities keep critical information moving — phone to phone, hop by hop, until it reaches someone who can help.

Built With

Share this project:

Updates

Submission history