feat(roadflare): silent mute + decoupled stale-key offer flow (ridestr side)

[variablefate]

Closes the ridestr-side scope of #82 + #83. roadflare-rider's DriverQuoteCoordinator and related screens will follow in a separate PR (matches the user-stated "one big PR per app" plan).

What this changes

Scope A — Silent mute (real)

The lightweight per-follower mute (#80) only suppressed key delivery; muted riders could still spam the driver with offers and pings. This PR adds the receive-side filter:

• New DriverRoadflareRepository.isAnyMuted(pubkey) unifies the heavyweight (MutedRider) and lightweight (RoadflareFollower.mutedAt) checks.
• DriverViewModel.processIncomingOffer (Kind 3173) drops muted offers silently.
• RoadflareListenerService.processPingEvent (Kind 3189) upgraded from heavyweight-only to isAnyMuted so lightweight-muted riders also can't wake the driver via ping.
• Kind 3187 / 3188 already check both paths (PRs fix(drivestr): treat Kind 3187 as delivery-retry, never rotate #79 / feat(drivestr): per-follower lightweight mute (#80) #81) — no change.

Twitter-style soft block: muted rider sees no response and falls back to another app (acceptable downgraded UX per product decision documented on #82).

Scope B — Decoupled stale-key offer flow

The RoadFlare key handshake conflated who can decrypt my live location (privacy gate) with who can effectively send me a ride offer (functional gate). Per the analysis on #82, those are independent — and since fare calc never strictly needs driver location (iOS proved this via ADR-0008, and Android already has the state.fareEstimate rider-route fallback at RiderViewModel.kt:1761), stale-key drivers should remain requestable.

The protocol already supports this: RoadflareLocationEvent.create() emits status and key_version as public tags alongside the encrypted lat/lon content. No schema change needed.

• New CachedDriverPresence(status, timestamp, keyVersion) channel on FollowedDriversRepository. Independent of CachedDriverLocation. Out-of-order guard built in.
• RoadflareDriverPresenceCoordinator.resubscribe:
  • Subscribes to ALL followed drivers (not just those with a current key).
  • Always extracts the public status + key_version tags via RoadflareLocationEvent.getStatus(event) / getKeyVersion(event) and updates driverPresence first.
  • Best-effort decryption afterwards; success → also updates driverLocations.
  • Out-of-order guard moved up so it applies to presence-only events too.
• RiderModeScreen.kt driver-list pipeline reads both signals. A driver is isOnline if EITHER decrypted location OR public presence says so. Per-driver fare quote still requires a known location; without one, the offer falls back to the rider-route fare automatically.
• isBroadcastEligible deliberately tightens to hasKey && locationOnline so the broadcast count matches what sendRoadflareToAll will actually attempt (geographic too-far cap requires real locations).
• isDirectSelectable stays loose — single-tap to a stale-key driver works.

Stale-signal piggyback (inline key recovery)

When the rider sends an offer to a driver they can't see the location of, fire a Kind 3188 status="stale" alongside. Driver receives both events together; the existing ack handler (#81) re-delivers the current Kind 3186 in response. By the time the driver accepts, the rider has the new key and can decrypt in-ride Kind 30014 updates.

• New private RiderViewModel.requestKeyRefreshAlongsideOffer(driverPubKey). Wired into sendRoadflareOffer and sendRoadflareOfferWithAlternatePayment. Fire-and-forget with explicit CancellationException rethrow; RoadflareTab.checkStaleKeys remains the periodic backstop for users not in the request flow.

Out of scope

• roadflare-rider (Android RoadFlare-only rider app): same Scope B treatment for DriverQuoteCoordinator, DriverNetworkTab, DriverSelectionScreen, RideTab. Will land in a follow-up PR per the "one big PR per app" plan.
• No UI hint for fallback fare — explicit product decision per fix(rider-app): wire per-driver-fare fallback to also cover stale/missing key case #83. Driver shows as available; rider sees the rider-route fare without qualifier; UX matches iOS.
• Heavyweight/lightweight mute API rename — naming is confusing but the rename is its own concern; tracked separately.

Acceptance criteria from #82 / #83

• Driver-side: muted rider's Kind 3173 offers don't appear in offer inbox.
• Driver-side: muted rider's Kind 3189 driver pings drop silently.
• Single isAnyMuted(pubkey) helper used by all four handlers (3173, 3187, 3188, 3189).
• Rider-side: stale-key driver appears as available in the driver list (no special UI state, matches iOS).
• requestRide() succeeds from stale-key state; sends Kind 3188 stale-signal alongside the offer.
• Driver-side: receiving an offer + stale-signal triggers Kind 3186 re-delivery via the existing feat(drivestr): per-follower lightweight mute (#80) #81 ack handler.
• :common:assembleDebug + :rider-app:assembleDebug + :drivestr:assembleDebug + :roadflare-rider:assembleDebug clean.
• :common:testDebugUnitTest + :rider-app:testDebugUnitTest + :drivestr:testDebugUnitTest green.
• Manual: drivestr + 2 rider clients. Mute rider A. Have A send a request → A sees no response, B unaffected.
• Manual: drivestr offline >12h, rider with stale key sends a request → driver receives offer + Kind 3188 stale-signal when next online; key re-delivers; ride proceeds.

🤖 Generated with Claude Code

[variablefate]

Code review

Found 4 issues:

1. Broadcast offer mute gap. subscribeToBroadcastRequests callback has no mute check, so a muted rider's broadcast Kind 3173 still lands in the driver's offer inbox. The PR's stated acceptance criterion ("muted rider's Kind 3173 offers don't appear in offer inbox") is only true for the direct/RoadFlare callback. Same driverRoadflareRepository.isAnyMuted(...) one-liner needed at the top of this callback.

ridestr/drivestr/src/main/java/com/drivestr/app/viewmodels/DriverViewModel.kt

Lines 3414 to 3433 in 4068fe9

	subs.set(SubKeys.BROADCAST_REQUESTS, nostrService.subscribeToBroadcastRideRequests(
	location = location,
	expandSearch = expandSearch
	) { request ->
	// Observability: should never fire after accept-time subscription closure
	if (BuildConfig.DEBUG) {
	val stage = _uiState.value.stage
	if (stage != DriverStage.AVAILABLE && stage != DriverStage.ROADFLARE_ONLY) {
	Log.w(TAG, "subscribeToBroadcastRequests callback during $stage — sub should be closed")
	}
	}
	Log.d(TAG, "Received broadcast ride request from ${request.riderPubKey.take(8)}, fare=${request.fareEstimate}")
	// Filter out requests we've already accepted
	if (request.eventId in acceptedOfferEventIds) {
	Log.d(TAG, "Ignoring already-accepted request: ${request.eventId.take(8)}")
	return@subscribeToBroadcastRideRequests
	}

2. RoadflareListenerService.subscribeToRoadflareRequests was not migrated to isAnyMuted. Two compounding gaps in the same callback: (a) it captures getMutedPubkeys() at subscribe-open time so mute changes after subscribe are invisible until service restart; (b) the heavyweight-only mutedPubkeys set means lightweight-muted (RoadflareFollower.mutedAt) riders still trigger the foreground-service notification path. Should use the live isAnyMuted(event.pubKey) check the PR introduces.

ridestr/drivestr/src/main/java/com/drivestr/app/service/RoadflareListenerService.kt

Lines 187 to 205 in 4068fe9

	private fun subscribeToRoadflareRequests(driverPubKey: String) {
	// Get muted pubkeys to filter
	val mutedPubkeys = driverRoadflareRepo?.getMutedPubkeys()?.toSet() ?: emptySet()
	subscriptionId = nostrService?.relayManager?.subscribe(
	kinds = listOf(RideshareEventKinds.RIDE_OFFER),
	tags = mapOf(
	"p" to listOf(driverPubKey),
	"t" to listOf(RideOfferEvent.ROADFLARE_TAG)
	)
	) { event, relayUrl ->
	// Skip if already seen (atomic check-and-add)
	if (!seenRequests.add(event.id)) return@subscribe
	// Skip if from muted rider
	if (event.pubKey in mutedPubkeys) {
	Log.d(TAG, "Ignoring RoadFlare from muted rider ${event.pubKey.take(8)}")
	return@subscribe
	}

3. FollowedDriversRepository.clearAll() omits the new _driverPresence map. The KDoc on clearAll() says "for logout" and explicitly clears _driverLocations (which has the same in-memory-only semantic), but the new _driverPresence is left intact. After logout + login as a different user in the same process, the previous user's presence data survives until the coordinator's next resubscribe overwrites it.

ridestr/common/src/main/java/com/ridestr/common/data/FollowedDriversRepository.kt

Lines 319 to 329 in 4068fe9

	* Clear all followed drivers and cached names/locations (for logout).
	*/
	fun clearAll() {
	prefs.edit()
	.remove(KEY_DRIVERS)
	.remove(KEY_DRIVER_NAMES)
	.apply()
	_drivers.value = emptyList()
	_driverNames.value = emptyMap()
	_driverLocations.value = emptyMap()
	}

4. requestKeyRefreshAlongsideOffer fires BEFORE setupOfferSubscriptions in both sendRoadflareOffer and sendRoadflareOfferWithAlternatePayment. The piggyback issues a Nostr publish round-trip; a fast-responding driver's Kind 3174 acceptance could arrive on the relay before the acceptance subscription is armed, and be silently missed. The piggyback should fire AFTER setupOfferSubscriptions, or the two should be launched concurrently.

ridestr/rider-app/src/main/java/com/ridestr/rider/viewmodels/RiderViewModel.kt

Lines 1825 to 1844 in 4068fe9

	val pickupRoute = calculatePickupRoute(driverLocation, pickup)
	val eventId = sendOfferToNostr(params, pickupRoute)
	if (eventId != null) {
	Log.d(TAG, "Sent RoadFlare offer to ${driverPubKey.take(16)}: $eventId")
	// Issue #82: stale-key piggyback. If we just sent an offer to a driver
	// we can't see the location of (no key OR stale key), fire a Kind 3188
	// status="stale" alongside so the driver re-delivers the current key in
	// the same beat. By the time they accept, we have the new key and can
	// decrypt the in-ride Kind 30014 updates. Fire-and-forget — failure
	// doesn't affect the offer, and `RoadflareTab.checkStaleKeys` covers the
	// periodic backfill.
	if (driverLocation == null) {
	requestKeyRefreshAlongsideOffer(driverPubKey)
	}
	setupOfferSubscriptions(eventId, driverPubKey, isBroadcast = false)
	applyOfferSuccessState(params, eventId)
	} else {
	applyOfferFailureState("Failed to send RoadFlare offer")
	}
	}

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[variablefate]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

Pass 2 verified the four pass-1 fixes (broadcast mute guard, RoadflareListenerService live mute check, clearAll presence, piggyback ordering) introduce no regressions. Re-audited the full PR for missed receivers, presence-channel observability, batch send + null-location, and out-of-order edge cases — all clean. One minor KDoc inaccuracy on isAnyMuted caller list addressed in e8def8f. PR ready for review.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[variablefate]

Code review

Found 3 issues (all addressed in c016c93):

1. removeDriver leaked the presence entry — symmetric clear was missed alongside locations + names. Concrete failure: remove + re-add same driver in one session, the same Kind 30014 (still within 5-min TTL) hits the existing.timestamp >= timestamp guard and the driver shows offline until next broadcast tick. Defeats the stale-key UX.

https://github.com/variablefate/ridestr/blob/11ac75cb04ea25a3ce3b566f06bd1e6c8a4e63c5/common/src/main/java/com/ridestr/common/data/FollowedDriversRepository.kt#L232-L242

2. updateDriverPresence had non-atomic check-then-act. Direct _driverPresence.value = assignment with a separate guard read means two relay threads (Dispatchers.IO) for the same pubkey can both pass the guard before either writes, and the lower-timestamp write can win — defeating the out-of-order protection the KDoc advertises. Migrated to StateFlow.update { } for CAS-retried atomic read-modify-write.

https://github.com/variablefate/ridestr/blob/11ac75cb04ea25a3ce3b566f06bd1e6c8a4e63c5/common/src/main/java/com/ridestr/common/data/FollowedDriversRepository.kt#L107-L114

3. lastLocationCreatedAt not pruned when drivers list shrinks. Same root cause as Driver app needs wallet setup screen in onboarding flow #1 — re-adding a removed driver in the same session leaves the prior session's lastLocationCreatedAt[pubkey] intact, gating the event at eventCreatedAt < lastSeen. Defense-in-depth fix alongside Driver app needs wallet setup screen in onboarding flow #1.

https://github.com/variablefate/ridestr/blob/11ac75cb04ea25a3ce3b566f06bd1e6c8a4e63c5/common/src/main/java/com/ridestr/common/roadflare/RoadflareDriverPresenceCoordinator.kt#L47-L60

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}