Offline Mesh SOS and Relief Messaging App for Flood-Hit Areas

The problem: the network goes down when it is needed most

During the 2022 floods in Pakistan, and in many disasters since, mobile towers lost power or were damaged, and whole areas were cut off for days. People stranded on rooftops or embankments often had phones with some charge but no signal. Rescue boats and relief teams had little information on where people were and what they needed, and when phones did reach a network, messages were scattered across calls, WhatsApp groups and social media.

Phones can talk to each other directly over Bluetooth and Wi-Fi. If a short SOS could hop from phone to phone until one reaches a relief camp or a working tower, information would flow even without networks.

What already exists and the gap

• Serval Mesh, from the Serval Project at Flinders University, pioneered phone-to-phone communication for disaster areas over Wi-Fi.
• Briar is an open source messenger that can sync over Bluetooth and Wi-Fi when the internet is down, designed for activists and journalists.
• Bridgefy offers Bluetooth mesh messaging and has been used at protests and events.

These tools focus on chat between people. The gap is a relief-specific design: short structured reports that rescuers can map, priority and expiry so urgent reports move first, deduplication so the same household does not appear ten times, and a gateway that turns everything into a single map for responders.

Inspiration

The Serval Project at Flinders University, led by Paul Gardner-Stephen, was started after the 2010 Haiti earthquake to keep phones communicating without infrastructure, and published research on resilient communications for disasters. Store-and-forward "epidemic" routing for partially connected networks, where messages are copied to each phone met until they reach a destination, is the classic starting point for the routing; your job is to tune it for battery, bandwidth and priority.

What you build

• People in an affected area open the app and fill a short form in Urdu or English: how many people, any children, elderly or injured, needs such as rescue, water or medicine. The phone attaches its last known location.
• Every phone with the app quietly exchanges reports with nearby phones, keeping the most urgent and recent ones.
• When any phone reaches the internet, or meets a relief team's gateway phone, it uploads everything it carries.
• Relief coordinators see a deduplicated map of reports, sorted by urgency and age.

The technically interesting part

• Efficient exchange. Two phones may meet for only seconds. Exchange compact summaries of what each holds, then send only the missing reports, most urgent first.
• Priority, expiry and storage limits. Decide how many reports each phone carries, when old ones expire and how priorities are set, then measure the effect of each rule.
• Deduplication. The same family may send several reports, or several neighbours may report the same group. Merge by location, time and content, without losing important updates.
• Battery. Scanning for peers drains batteries that cannot be recharged. Design a duty cycle and measure its cost.
• Simulation. Write a simulator with realistic movement (people walking to high ground, boats, a relief camp) to compare strategies at a scale you cannot test in the field.

How to evaluate it

• Delivery rate and delay in simulation for different routing and priority strategies.
• Battery use per hour on real phones in different scanning modes.
• Field test: ten or more phones carried by volunteers around a campus or village with no internet, with one gateway; record how many reports arrive and how fast.
• Coordinator view: walk a relief worker or Rescue 1122 volunteer through the dashboard and record their feedback.

Suggested plan

• Weeks 1 to 4: study Serval, Briar and Nearby Connections; design the report format.
• Weeks 5 to 10: peer discovery and exchange between two phones, then many.
• Weeks 11 to 15: simulator and routing experiments.
• Semester 2, weeks 1 to 6: priority, expiry, deduplication and battery tuning.
• Semester 2, weeks 7 to 12: gateway, dashboard and field test.
• Semester 2, weeks 13 to 15: report and demo.

Path to a product

Disaster management authorities, rescue services and humanitarian NGOs need tools that work when networks fail, and preparedness programmes can install apps before the monsoon. An open source app with support from NGOs or government preparedness funds is the realistic route. The project shows distributed systems, mobile and field-testing skills that stand out on any CV.

Scope warning

The app must never be presented as a replacement for official emergency numbers; say clearly that it is a backup. Do not build general chat; keep messages structured and short. Test on volunteers in safe settings only, and treat location data as sensitive.

Learn what you need on Sefism

• Mobile development roadmap: Android services, storage and permissions.
• Network engineering roadmap: the networking ideas behind mesh and store-and-forward.
• Android Developers Documentation: background work and battery limits.
• Designing Data-Intensive Applications: replication and eventual consistency, which this app relies on.
• Mobile development cheat sheet: background tasks and testing on real devices.

Get help with this idea

The hard parts are routing that works in brief encounters and a field test that tells you something real. Tauseef can help you design the simulator, scope the field test and keep the app focused on relief. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session