trails-cool/trails
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trails/docs/ideas/mobile-nearby-sync
History
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
..
specs/mobile-nearby-sync Park mobile-activity-recording + mobile-nearby-sync under docs/ideas 2026-04-19 08:23:44 +02:00
.openspec.yaml Park mobile-activity-recording + mobile-nearby-sync under docs/ideas 2026-04-19 08:23:44 +02:00
proposal.md Park mobile-activity-recording + mobile-nearby-sync under docs/ideas 2026-04-19 08:23:44 +02:00
README.md Park mobile-activity-recording + mobile-nearby-sync under docs/ideas 2026-04-19 08:23:44 +02:00

README.md

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)