Privacy-Utility Trade-offs in Geo-Scoped P2P Traffic Dissemination

Consumer navigation apps like Google Maps and Waze aggregate live location and traffic data through a centralized backend, giving one commercial entity continuous visibility into their entire user base's movement. This thesis designs and evaluates a decentralized alternative: mobile nodes turn local mobility measurements into short-lived, privacy-reduced road-segment speed and hazard observations, and exchange them directly with nearby peers over geographically-derived iroh-gossip topics — no central traffic-data collector in the loop.

Centralized traffic systems yield high-quality, low-latency estimates, but at the cost of giving one party continuous visibility into everyone's movement patterns. Can a peer-to-peer alternative deliver comparable operational utility — dissemination speed, traffic accuracy, route quality — while measurably reducing that location exposure?

An ongoing MSc thesis at the University of Basel. Phase 1 (proposal and design: system architecture, four research questions, evaluation methodology) is complete, and a working prototype plus a real navigation-website addendum have already been implemented ahead of the full evaluation.

I designed the full system architecture and implemented every component of the Rust workspace end-to-end: the gossip protocol and privacy-reduced message schema, the geo-topic manager, the rendezvous/bootstrap service, a centralized-broker baseline for comparison, a synthetic mobility-simulation harness, a live monitoring dashboard, and a real navigation website with self-hosted routing and live P2P traffic/hazard sharing and chat.

• A Rust P2P node built on iroh and iroh-gossip
• Geo-topic derivation and subscription strategy (H3 cells, not one permanent city-wide topic)
• A minimal rendezvous/bootstrap mechanism that never sees traffic observations or raw GPS
• Signed, TTL-bounded traffic and hazard messages with local deduplication and confidence aggregation
• A controlled centralized-broker baseline for fair comparison on identical input data
• A mobility-input bridge (synthetic grid simulation, standing in for SUMO/TraCI)
• Measurement instrumentation and reproducible experiment scripts
• At least one routing/ETA-usefulness experiment

Each client pipeline runs: mobility input → local map matching → an observation reducer → a geo-topic manager deriving H3-cell-scoped gossip topics → the iroh-gossip actor → signature validation and deduplication → a local traffic-state store → a routing adapter applying a congestion-multiplier cost overlay → the map/alert client. See the pipeline diagram below. The rendezvous service sits alongside this pipeline and only ever maps geo-topic IDs to short-lived peer endpoints — never traffic data.

Built as a Rust Cargo workspace of seven crates: a shared protocol library (message schema, pseudonymous signing, H3 topic derivation, TTL/dedup/confidence store), a synthetic mobility simulator, the P2P/central-mode node binary, the rendezvous service, the centralized-broker baseline, a live web dashboard, and the navigation webapp. The webapp self-hosts OSRM in Docker for two real regions (Basel and Tirana), renders an OpenStreetMap/Leaflet map, and lets a user compute a real route, simulate driving it, and gossip live speed/hazard observations to nearby users — entirely peer-to-peer.

The largest architectural challenge was rendezvous: a geo-topic ID alone doesn't discover peers, so a node needs to learn at least one already-participating peer before it can join a topic's gossip swarm — without that rendezvous service ever seeing traffic observations or raw coordinates. A concrete bug then followed directly from that design: a node that joined a geo-topic before anyone else had registered would learn about later peers only one-directionally — it could be dialed, but never dialed anyone itself.

Fixed the one-directional connectivity bug by re-running rendezvous discovery and calling iroh-gossip's peer-join for already-joined topics too, both on every position update and on a five-second background timer. Kept the privacy property intact throughout: the rendezvous service only ever maps geo-topic IDs to short-lived peer endpoint addresses.

Evaluation is currently in progress. Preliminary implementation milestones are shown above: the full Rust workspace (protocol library, mobility simulator, P2P/central-mode node, rendezvous service, centralized-broker baseline, live dashboard) is built and running, alongside a real navigation website with self-hosted OSRM routing for Basel and Tirana and live P2P traffic/hazard gossip. The formal RQ1–RQ4 evaluation — dissemination latency and coverage, traffic-estimation and route-utility loss versus the centralized baseline, the privacy-utility trade-off across geo-topic resolutions, and robustness against false reports — has not yet been run.

Building a real, usable product (the navigation website) alongside the research prototype surfaced bugs — like the one-directional gossip issue — that a pure simulation never would have: it only appeared with real multi-process peers joining a swarm at different times.

• Replace the synthetic mobility simulator with real SUMO/TraCI integration
• Add a routing adapter that consumes live segment-speed estimates as edge-cost multipliers for an external routing engine
• Run the full experiment matrix (participation rate × density × topic resolution × network conditions) for the RQ1–RQ4 evaluation
• Explore DHT-based rendezvous and geo-indistinguishability as stronger privacy mechanisms
• ML-based congestion estimation combining live weather conditions with the spatial density of nearby peer reports