Ullrich Schäfer 621d91e14f

Park mobile-activity-recording + mobile-nearby-sync under docs/ideas

Both are blocked on the mobile-app foundation and on a user base that
actually records activities or needs offline peer sync. With 3 users
and 0 activities on prod today, these are engineering for a
hypothetical population.

Move the artifact sets out of openspec/changes/ (so openspec list
stays clean) and under docs/ideas/ where self-host-overpass already
lives. Each gets a short README documenting:

- current parked status
- revive triggers (when should we look at this again?)
- key constraints not to rediscover (background-GPS privacy review;
  BLE dev-build requirement; QR-only subset as a cheaper path)

Reviving is `git mv docs/ideas/<name> openspec/changes/<name>` and
running /opsx:apply, same pattern as self-host-overpass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-19 08:23:44 +02:00

1.8 KiB

Raw Blame History

mobile-nearby-sync (parked)

OpenSpec change for sharing routes between nearby devices without internet (BLE-based peer sync + QR-code waypoint fallback) in the mobile app. Moved here from openspec/changes/ so it does not clutter the active change list; revive by moving the directory back under openspec/changes/ when ready to implement.

Status

Parked. Blocked on mobile-app landing first, and on there being enough users actually hiking/bikepacking together to justify the BLE complexity. At the current user count (3) this is engineering for a hypothetical group trip.

When to revive

Revisit once any of these is true:

The mobile app is live and users start reporting "we were in a dead zone and couldn't update the route"
A group / tour organiser asks specifically for peer-to-peer route sync
QR-code waypoint sharing alone (the simpler half of this spec) would cover the need — worth shipping that first as a narrower change

Key constraints to remember

Requires an Expo dev build — react-native-ble-plx isn't available in Expo Go.
iOS + Android BLE APIs differ significantly; expect platform-specific bugs. Background BLE advertising has battery and OS-lifecycle caveats (iOS suspends advertising when backgrounded after a grace period).
Permissions sprawl: iOS NSBluetoothAlwaysUsageDescription, Android BLUETOOTH_SCAN + BLUETOOTH_CONNECT + BLUETOOTH_ADVERTISE, plus location on older Android.
QR waypoint sharing is an order of magnitude simpler than BLE and covers a big chunk of the use case — consider extracting that as a separate, earlier change if the need becomes real.

What's in the folder

proposal.md — why / what / non-goals / impact / future ideas (TXQR)
specs/ — delta specs (would land against a new mobile-nearby-sync capability)

1.8 KiB Raw Blame History