Wayrelay

Keeping life-saving information moving when everything else stops

Comment

Inspiration

During natural disasters, the first casualty is often infrastructure. Cell towers lose power, fiber lines are severed, and centralized servers become completely unreachable. When people are desperately searching for shelter, food, or medical clinics, standard cloud applications fail.

We were inspired to create a system that survives the collapse of infrastructure—a digital lifeline that uses the devices already in people's pockets to route critical capacity data hand-to-hand across a disaster zone.

What it does

Wayrelay (a portmanteau of waypoint and relay) is a zero-infrastructure mesh network for real-time crisis matching.

Instead of relying on a centralized cloud, Wayrelay allows smartphones to pass live capacity data from device to device over a local mesh.

  • Live OSM Streaming: When online, the backend actively streams real-world infrastructure data (hospitals, shelters) based on the user's GPS using the OpenStreetMap (OSM) Overpass API, rather than relying on a static database.
  • Zero-Infrastructure: When the connection drops, it requires no towers or servers to function locally.
  • True Offline PWA: A user can open the Wayrelay Demo once, and the Service Worker caches it entirely. It will load perfectly forever, even in Airplane mode.
  • Self-Healing Data: Every resource envelope has a built-in Time-To-Live (TTL). Listings automatically age out before they can mislead evacuees.

How we built it

We built Wayrelay focusing on absolute resilience and maximum compatibility using a pure HTML/CSS/JS stack.

To simulate the Bluetooth peer-to-peer data synchronization in the browser without requiring physical BLE hardware for the demo, we built a custom MeshEngine. It uses a CRDT-style (Conflict-free Replicated Data Type) structure to dynamically merge incoming resource envelopes:

// Example of our mesh merging logic
receiveEnvelopes(incoming) {
  let updated = 0;
  for (const env of incoming) {
    const existing = this.store.get(env.id);
    // Only accept newer timestamped data
    if (!existing || env.lastUpdated > existing.lastUpdated) {
      this.store.set(env.id, { ...env });
      updated++;
    }
  }
  return updated;
}

To display only the most relevant resources to the user, we implemented the Haversine formula directly in the client to calculate the great-circle distance between the user's GPS coordinates and the resource node. The distance ( d ) is calculated as:

$$ d = 2r \arcsin\left(\sqrt{\sin^2\left(\frac{\Delta\phi}{2}\right) + \cos\phi_1\cos\phi_2\sin^2\left(\frac{\Delta\lambda}{2}\right)}\right) $$

Where ( \phi ) represents latitude, ( \lambda ) represents longitude, and ( r ) is Earth's radius (6,371 km).

Challenges we ran into

Building an application that must work offline is incredibly difficult.

  1. Aggressive Caching vs Live Data: Getting our Service Worker to properly manage the application lifecycle while intercepting network failures was a major hurdle. If the live OSM stream fails, our Service Worker intercepts the crash and seamlessly injects a zero-infrastructure emergency dataset directly into the local mesh. At one point, our own offline-first architecture worked too well, trapping test devices in old caches!
  2. Data Decay Algorithms: Implementing mathematical decay for resource relevance. We had to ensure that the validity of an emergency broadcast decays linearly over time:

$$ Validity = \max\left(0, 1 - \frac{T_{now} - T_{broadcast}}{TTL_{max}}\right) $$

Accomplishments that we're proud of

  • The "Zero-Bar" Fallback: A user can turn on Airplane Mode, refresh the app, and still have full access to an interactive, localized map of emergency resources generated purely from the device's persistent mesh cache.
  • The Mesh UI: We successfully translated a complex networking concept (Bluetooth hop routing and mesh flooding) into a highly intuitive, chat-like interface.

What we learned

We learned that the modern web platform is incredibly powerful for offline applications if you are willing to dive deep into the Cache API. We also learned how difficult it is to maintain data consistency without a central source of truth, validating our decision to use timestamped, mathematically decaying envelopes.

What's next for Wayrelay

  • Native BLE Integration: Wrapping the web application in a React Native shell to gain direct access to the device's Bluetooth Low Energy (BLE) APIs.
  • SMS Fallback Gateway: Implementing a Twilio-based gateway so that feature phones can text a specific number to query the mesh network.

Built With

Share this project:

Updates

Submission history