Goal
Build true live (sub-second to few-second cadence) ephemeral location streaming between driver and rider during an active ride, replacing or augmenting the current periodic Kind 30012 location-update model. Rider sees the driver's car move smoothly on the map; driver sees the rider's pickup point updating if they walk to a different spot.
"Ephemeral" — these updates are not persisted to relays for archival, only relayed for the duration of the active ride session, then forgotten.
Why it matters
The current ride flow shows the driver's location only when their last Kind 30012 update happened to land. There's a perceptible gap between "driver has arrived" fired and the driver actually being visible at the right pin. A live channel closes that gap and matches the UX riders expect from any other ride app.
Equally important on the driver side: knowing the rider has stepped 50 feet down the block to a better pickup spot, without forcing the rider to chat-message coordinates.
Cross-platform contract
This must be designed with the ridestr Android Drivestr app in mind from day one — not as an iOS-only feature with an Android port slapped on later. Symmetric protocol, symmetric UX, symmetric battery profile.
Companion issue in ridestr to be filed alongside this one, capturing the same scope from the driver-app perspective. Both should land together (or with whichever ships second feature-flagged off until the other is ready).
Open design questions (for the brainstorming pass)
- Transport. Nostr ephemeral events (Kind 20000–29999 range, not stored by relays per NIP-01)? A direct rider↔driver encrypted channel via NIP-44 over a relay? WebRTC data channel for true peer-to-peer (relays just for signaling)?
- Cadence. Fixed (e.g. 2 Hz)? Adaptive (faster when distance closing, slower at constant velocity)?
- Battery. Continuous GPS at high accuracy is expensive. What's the lower bound on sample rate that still feels "live"? When does the channel pause (driver stationary > N seconds)?
- Backgrounding. iOS limits background location updates aggressively. Need to verify the ride-active state qualifies for
allowsBackgroundLocationUpdates continuous streaming, or if we fall back to significant-change events.
- Privacy. Ephemeral by design — make sure no relay implementation accidentally archives. Verify against actual relay behaviors for our chosen kind range.
- Coexistence with current model. Kind 30012 stays for "last known location" outside an active ride? Live channel only operates inside an active ride session?
- Map rendering. Smooth interpolation between samples on the rider's map, or step-update? Animation curves matter for perceived smoothness.
Prerequisites
- Some of this overlaps with #28's LocationCoordinator extraction (already shipped) — the SDK location pipeline is a clean place to plug in a new ephemeral channel without disturbing the existing periodic flow.
- Core ride state machine in
RidestrSDK already tracks active ride sessions; the live channel should hook lifecycle to those transitions (start at enRoute, stop at completed/cancelled).
Suggested approach
- Spec doc first. Write up the protocol design (kind, payload, encryption, cadence, lifecycle) as a doc in
docs/superpowers/specs/ and circulate before any implementation. This is exactly the kind of cross-platform contract change that benefits from being written down once and ratified, rather than discovered via two parallel implementations diverging.
- Prototype in SDK. Add an
EphemeralLocationChannel type in RidestrSDK with sender/receiver halves, with the network layer mockable for tests. Both apps consume the same SDK type.
- Wire into both apps. Drivestr publishes; RoadFlare iOS consumes (and vice versa for rider→driver pickup-spot updates).
- Land an ADR. Per repo CLAUDE.md, this is exactly the "new public API surface (SDK or app)" + "shifting module boundaries" + "pattern touching >3 files" trifecta that warrants an ADR.
Priority
P3 — major feature, future enhancement. Not on the App Store v1.0.x path. Schedule when the immediate trust-eroding bugs (#68 silent relay failures, #72 stale-key handling, #73 first-add subscription regression) are resolved and the basics feel solid.
Companion
Mirror issue to be filed in the ridestr repo for the driver-app side. Cross-link added in a follow-up comment once the ridestr issue number is known.
Goal
Build true live (sub-second to few-second cadence) ephemeral location streaming between driver and rider during an active ride, replacing or augmenting the current periodic Kind 30012 location-update model. Rider sees the driver's car move smoothly on the map; driver sees the rider's pickup point updating if they walk to a different spot.
"Ephemeral" — these updates are not persisted to relays for archival, only relayed for the duration of the active ride session, then forgotten.
Why it matters
The current ride flow shows the driver's location only when their last Kind 30012 update happened to land. There's a perceptible gap between "driver has arrived" fired and the driver actually being visible at the right pin. A live channel closes that gap and matches the UX riders expect from any other ride app.
Equally important on the driver side: knowing the rider has stepped 50 feet down the block to a better pickup spot, without forcing the rider to chat-message coordinates.
Cross-platform contract
This must be designed with the ridestr Android Drivestr app in mind from day one — not as an iOS-only feature with an Android port slapped on later. Symmetric protocol, symmetric UX, symmetric battery profile.
Companion issue in ridestr to be filed alongside this one, capturing the same scope from the driver-app perspective. Both should land together (or with whichever ships second feature-flagged off until the other is ready).
Open design questions (for the brainstorming pass)
allowsBackgroundLocationUpdatescontinuous streaming, or if we fall back to significant-change events.Prerequisites
RidestrSDKalready tracks active ride sessions; the live channel should hook lifecycle to those transitions (start atenRoute, stop atcompleted/cancelled).Suggested approach
docs/superpowers/specs/and circulate before any implementation. This is exactly the kind of cross-platform contract change that benefits from being written down once and ratified, rather than discovered via two parallel implementations diverging.EphemeralLocationChanneltype in RidestrSDK with sender/receiver halves, with the network layer mockable for tests. Both apps consume the same SDK type.Priority
P3 — major feature, future enhancement. Not on the App Store v1.0.x path. Schedule when the immediate trust-eroding bugs (#68 silent relay failures, #72 stale-key handling, #73 first-add subscription regression) are resolved and the basics feel solid.
Companion
Mirror issue to be filed in the ridestr repo for the driver-app side. Cross-link added in a follow-up comment once the ridestr issue number is known.