Problem Statement
Coastal, mountain, and post-typhoon barangays routinely lose signal for hours or days. Facebook pages and GCs die with the tower. Yet announcements — water cutoff, relief lineup, evacuation order — still need to move within the barangay. Paper works but is slow and single-copy; runners can’t cover 7 puroks at night.
Proposed Solution
MeshBalita lets any Android phone broadcast signed barangay posts that hop phone-to-phone over Bluetooth LE/WiFi-Direct, plus an optional ₱1,500 ESP32 LoRa relay at the hall for long hops. Posts are queued in SQLite with priority (emergency first). An on-device summarizer compresses long assembly minutes into 3-bullet TL;DRs. No account server; barangay secretary holds a signing key on a hall laptop. Any carrier, any SIM, or no SIM.
Target Market
- Primary users: Barangay secretaries, tanods, purok leaders in dead-spot and disaster-prone areas.
- Deployers: MDRRMOs for contingency comms, people’s organizations, island cooperatives.
How AI Is Used
- On-device summarizer: Compresses minutes and advisories into short bulletins; essential when LoRa bytes are precious.
- Priority classifier: Tiny model tags emergency vs routine so radios send rescue first.
- Deduplication: Embedding match merges re-forwarded copies of the same announcement.
Independent Deployment Angle
- Zero dependency on any telco core, cloud, venue, or headset. Community owns the relays and keys.
- Built from palengke parts: ESP32, USB powerbank, recycled phones.
- Any volunteer can reflash and re-deploy; docs are one page in Tagalog.
Demo Scenario (3 minutes for judges)
- Three phones in airplane mode + Bluetooth on. Secretary posts “Relief bukas 8AM, dalhin ang stub.”
- Message hops phone 1 → 2 → 3 with hop counter and signature check.
- Secretary posts 2-page minutes; on-device TL;DR appears as 3 bullets before sending.
- Emergency post (“Baha sa Purok 5”) jumps the queue ahead of routine posts.
- Close: “No bars. Still informed.”
30-Hour Build Plan
| Hours | Task | Role |
|---|---|---|
| 0–3 | Scope mesh libs, buy/borrow ESP32, define post schema | All |
| 3–10 | BLE/WiFi-Direct hop prototype + signature check | Backend |
| 3–12 | On-device summarizer + priority classifier | AI lead |
| 10–20 | Queue UI, LoRa relay firmware | Backend + Frontend |
| 20–26 | 3-phone + relay field test in building | All |
| 26–30 | Demo script, pitch, disclosure | PM / Pitch |
Suggested stack: Flutter + Bluetooth LE / WiFi-Direct mesh, ESP32 LoRa relay, SQLite sync queue, TinyLM summarizer on-device. Public data / APIs: None required; uses team-written sample bulletins.
Risks & Privacy Notes
- Misinformation: Only signed hall posts auto-trust; unsigned rumors labeled clearly. Secretary can revoke keys.
- Privacy: No cloud, no personal data collection. Demo uses synthetic names and puroks; no real resident data into AI tools.
- IP: Mesh libs and model licenses documented; team owns post schema.
- Range limits: Honest about LoRa throughput; text-only in emergency mode.
AI Use Disclosure (draft)
MeshBalita uses a tiny on-device LM for summarization and classification plus embedding dedup. AI coding assistants helped with mesh boilerplate. All summaries in the demo were human-checked for meaning preservation.
Rubric Scoring
| Criterion | Weight | Score (1–5) | Why |
|---|---|---|---|
| Innovation & creativity | 25% | 5 | Phone-to-phone barangay mesh with AI compression is fresh |
| Problem–solution fit | 25% | 4 | Strong for dead spots; needs behavior change |
| AI application & value | 20% | 3 | Small but essential models |
| Feasibility | 15% | 3 | Mesh + LoRa in 30h is tight but demoable |
| Impact & scalability | 15% | 4 | Every island barangay benefits |
| Weighted total | 4.10 |