1. The Objective
In modern urban and disaster-stricken zones, centralized communication infrastructure is highly fragile. Natural disasters (such as the 2023 Turkey-Syria Earthquake), physical damage to cellular nodes, power grid failures, and state-backed internet shutdowns leave civilians and first responders in an information vacuum. Standard digital coordination tools become useless "bricks" because they depend on a fragile, always-on client-server handshake.
Pigeon was engineered to solve this "Zero-Infrastructure" crisis. Moving away from traditional message-oriented delivery, Pigeon treats disaster data under an Information-Oriented Epidemic Model. Every smartphone functions as an independent node in a distributed, local-first ledger, enabling situational awareness to propagate seamlessly through opportunistic peer-to-peer synchronization.
Our key system objectives included:
- Zero Centralized Dependency: Complete operation with no SIM cards, cellular towers, Wi-Fi routers, or satellites.
- Store-and-Forward Epidemic Routing: Ensuring a local report eventually reaches all surrounding nodes via human mobility (data flowing dynamically like a digital virus).
- Solving the Battery-Utility Paradox: Minimizing radio up-time so the application can remain active on a survivor's device for days rather than hours.
- Decentralized Trust & Moderation: Mitigating misinformation and Sybil attacks in a trustless environment without central authority.
2. The Architecture
Pigeon utilizes a Decentralized Layered Architecture. By decoupling the presentation, storage, and transport protocols, the core engine remains hardware-agnostic, low-latency, and highly maintainable.
System Decoupling & Core Layers
- Presentation Layer (Jetpack Compose): Built with strict high-contrast styling and large 48dp touch targets to maintain usability under extreme physical stress, low visibility, or smoke-filled environments.
- Transport & Exchange Layer (Google Nearby Connections): Coordinates localized peer-to-peer discovery over a
P2P_CLUSTERtopology. It utilizes low-power Bluetooth Low Energy (BLE) for ambient background node discovery, shifting dynamically to high-speed Wi-Fi Direct sockets only during active data sync windows. - Storage Ledger Layer (Room SQLite DB): Acts as an ACID-compliant local database. Data is appended via an immutable, "Insert-Only" structure to prevent historic tampering and maintain a local cryptographic audit trail. Databases are normalized to Third Normal Form (3NF) to minimize packet footprint.
End-to-End Data Lifecycle Flow
- Local Incident Ingestion: When a user logs a critical event (e.g., medical emergency, localized structural hazard), the payload is instantly serialized into a highly compressed binary Protocol Buffer format and staged locally in the Room DB with a state of
PENDING_BROADCAST. - Opportunistic Connection Handshake: The NearbySyncManager actively cycles background radios. When two moving human nodes pass within hardware range, a short cryptographic handshake occurs to authenticate the peer and check for data discrepancies.
- Delta-Driven Sync Exchange: Instead of broad database cloning, the custom Set Union Engine evaluates the symmetric differences between local and remote manifest hashes. Only missing event records are exchanged over a transient Wi-Fi Direct link.
- Epidemic Propagation & Convergence: Upon receiving missing deltas, the peer validates packet authenticity, drops duplicate data signatures, commits the records to its own immutable ledger, and prepares to act as an active store-and-forward courier to the next encountering node.
System Layers & Data Paradigm
- Sync/Exchange Layer: Interfaces with the Google Nearby Connections API using the
P2P_CLUSTERtopology. This layer coordinates low-power background discovery over Bluetooth Low Energy (BLE) and negotiates transitions to high-speed Wi-Fi Direct for payload transfers. - Data Layer (The Ledger): An ACID-compliant local database managed via Room Persistence. All data is written under an immutable, "Insert-Only" append structure, ensuring a consistent audit trail. Databases are strictly normalized to Third Normal Form (3NF) to keep payload sizes minimal.
- Control Layer (The Ping System): Orchestrates the state transitions between the Off, Passive, and Active radio modes based on local user activity and external peer signals.
3. The Core Engineering Triumphs
Custom Set Union Engine (Delta-Only Synchronization)
Instead of exchanging complete database catalogs during a peer handshake, which causes network congestion and radio battery depletion, the SetUnionEngine utilizes a stateful synchronization flow.
When two devices connect, they exchange a lightweight Manifest Hash representing their current record list. The engine identifies the symmetric difference between the local and remote sets. Only the missing data "deltas" (new incidents or verification objects) are transmitted, maintaining $O(n)$ efficiency, where $n$ is the number of new records.
Binary Protocol Buffers vs JSON
To reduce the "On-Air" transmission time of the physical radios, standard JSON serialization was replaced with binary Protocol Buffers (Protobuf) using a unified PigeonPayload structure. This reduced individual payload sizes by approximately 60%, ensuring synchronization handshakes complete in milliseconds before the device's radios "Race to Sleep."
Overcoming the OEM Connection Bug
During multi-device testing (using Samsung and Pixel hardware), we encountered an API sensitivity where two devices set to "Active" failed to discover and sync. The team solved this by writing a custom wrapper that ensures the "Active" state explicitly calls startDiscovering() and startAdvertising() simultaneously. This guaranteed that any two nodes within discovery range would successfully establish a socket, regardless of local state.
High-Performance Power State Scheduler
// The 3-State Power state transitions managed by the NearbySyncManager
fun setRadioState(state: RadioState) {
when (state) {
RadioState.OFF -> {
stopAdvertising()
stopDiscovery()
disconnectAllPeers()
}
RadioState.PASSIVE -> {
// "Guardian Mode" utilizing low-energy BLE advertising
startAdvertising(Strategy.P2P_CLUSTER)
stopDiscovery() // Avoids high-power Wi-Fi scanning
}
RadioState.ACTIVE -> {
// High-power sync phase
startAdvertising(Strategy.P2P_CLUSTER)
startDiscovery(Strategy.P2P_CLUSTER)
// "Race to Sleep" guard timer (60-second timeout to transition back to PASSIVE)
startInactivityTimer(60_000) {
setRadioState(RadioState.PASSIVE)
}
}
}
}
4. Empirical Impact & Metrics
Pigeon underwent rigorous real-world field trials at the Lebanese American University (LAU) Campus to evaluate convergence speed and power efficiency under realistic post-disaster conditions.
A. Battery Profiling (Solving the Battery-Utility Paradox)
Continuous active scanning in standard mesh applications drains a modern smartphone in less than 6 hours. Pigeon's custom 3-State Power Logic resolves this constraint:
| Mode | Radio State | Avg. Background Drain (%/hr) | Estimated Operational Runtime |
|---|---|---|---|
| Standard Mesh Apps | Always-On (Active Wi-Fi) | 18.5% | ~5.4 Hours |
| Pigeon PASSIVE | BLE Advertising | 2.1% | ~47.6 Hours |
| Pigeon Dynamic | 3-State Toggle Scheduler | 4.2% | ~23.8 Hours |
Result: The Dynamic state machine provides a 4.4× increase in operational lifespan compared to traditional "always-on" mesh solutions, easily sustaining a device over a critical 24-hour blackout cycle.
B. Mesh Convergence (The University Campus Walk Case Study)
To simulate a scenario where direct communication between the "Source" (Device A) and "Responder" (Device C) was blocked by concrete shielding and geographic distance (350 meters), a third mobile node (Device B) acted as an opportunistic courier.
| Test Run | Incident Type | Node A to B Sync | Node B to C Sync | Total Mesh Convergence Time |
|---|---|---|---|---|
| 1 | SOS Alert | 4.2s | 3.8s | 58s |
| 2 | Fire Hazard | 3.1s | 3.5s | 42s |
| 3 | Medical Emergency | 5.5s | 4.1s | 65s |
| Avg | — | 4.26s | 3.80s | 55 seconds |
Result: The average peer-to-peer handshake latency of 4.26 seconds confirms that data transfer completes easily during a brief "pass-by" encounter where two walking nodes are in range for less than 10 seconds.
C. Validation & Benchmarks
- Offline Mapping Performance: MapLibre successfully rendered cached vector tiles (.mbtiles) in < 500ms during continuous offline pan/zoom gestures.
- Set Union Efficiency: Sync manifest packets stayed < 2KB for a batch of 50 incidents, preserving precious bandwidth.
- Identity Lockout Security: Attempted profile/callsign changes within the 72-hour window (259,200,000ms) were successfully blocked on-device, successfully mitigating Sybil and coordinate spoofing attacks.