From b348a9944a9aff02e197fbdd869fc87fe48a580b Mon Sep 17 00:00:00 2001 From: Mathieu Moran Date: Sun, 9 Aug 2026 20:32:27 -0400 Subject: [PATCH] Plan remote trip portal Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- PLAN.md | 42 ++++++++++++++++++++++++++++++++++++++---- readme.md | 6 ++++-- 2 files changed, 42 insertions(+), 6 deletions(-) diff --git a/PLAN.md b/PLAN.md index fe55e64..5e5cca7 100644 --- a/PLAN.md +++ b/PLAN.md @@ -1093,12 +1093,46 @@ remaining cleanup once all the functional phases above have landed: framework rewrite would add deployment weight and offline assets on the Pi without improving the tracker features, and would discard the foundation deliberately built before Phases 16-21. -### Phase 23: Native Android companion app — 🚧 PLANNED (low priority, do last) +### Phase 23: Remote trip portal with shared web UI — 🚧 PLANNED +**Added 2026-08-09; intentionally scheduled after Phase 22.** Phase 22 first establishes the final +visual language and complete in-car interface. Building the remote portal afterward avoids +duplicating the current unfinished theme and lets both deployments deliberately share the same +finished shell, components, trip list, route map, timeline replay, units, and responsive behavior. + +Extend the existing self-hosted `server/` deployment from an upload-only API into a secure remote +web portal backed by its Postgres tracking data, so trip history and all recorded trip details can +be viewed away from the car: +- Add server-side trip boundary/index data equivalent to Phase 18, generated from uploaded tracking + points without changing or deleting the raw records. Expose trip summaries, full/downsampled + routes, timestamps, distance in km/mi, average/max speed in km/h and mph, and timeline replay. +- Reuse the redesigned Phase 22 Jinja/Bootstrap UI rather than creating a visually separate app. + Extract/share presentation assets where practical so local and remote pages do not drift, while + keeping their data providers and available actions explicit. +- Put an always-visible environment indicator in the shared shell: **In-car / Local Pi** on + `yaris.local`, and **Remote server** on the hosted portal. Page title, navigation, and status + styling must also make the context unambiguous so the user cannot mistake remote historical data + for a live connection to the car. +- The remote portal is primarily historical/read-only. Hardware-only actions (physical dashcam + mount/delete/import, live OBD/GPS state, Pi settings) must be hidden, disabled with a clear + explanation, or replaced by their remote equivalent rather than appearing to control the car. + Uploaded dashcam archive browsing can be included if it reuses the existing server storage + safely, but trip detail/replay is the required first scope. +- Add real human-user authentication and secure sessions for the internet-facing UI. Existing + device `X-Device-Name`/`X-Api-Key` upload authentication remains separate and must not become a + browser login mechanism. Preserve Cloudflare Tunnel compatibility and do not expose secrets in + HTML/JavaScript. +- Support selecting a vehicle/device if more than one is registered later, while defaulting + cleanly to the current Yaris. Keep trip APIs scoped to the authenticated user/device. +- Deploy only after Phase 22 is complete: rebuild the unraid Docker stack, verify migrations against + copied data first, compare remote trip calculations with uploaded Pi records, and browser-test + desktop/mobile through the real hosted endpoint before committing. + +### Phase 24: Native Android companion app — 🚧 PLANNED (low priority, do last) Revives the phone-relay goal (Phase 11/12) properly this time, using a real native app instead of a web page - the only way to actually hold a WiFi connection to the Pi's hotspot and a cellular connection to the internet open simultaneously (`ConnectivityManager.bindProcessToNetwork()`, unavailable to browser JS - see the Phase 11 update). Explicitly **not urgent** - deprioritized to -the end of the roadmap, after all web-side work (Phases 12-22) is done. Scope, at a high level +the end of the roadmap, after all web-side work (Phases 12-23) is done. Scope, at a high level (not yet designed in detail): - **Dashcam file transfer**: browse/select/delete dashcam clips already imported to the Pi (same data as the Phase 17 local video browser, just a native client instead of/alongside the web UI), @@ -1111,8 +1145,8 @@ the end of the roadmap, after all web-side work (Phases 12-22) is done. Scope, a - Not yet scoped: distribution (sideload vs Play Store), whether it talks to the Pi directly over the hotspot only or also to the remote server directly for trip history when away from the car, and how much of the existing REST API surface can be reused as-is vs needs new - mobile-friendly endpoints. To be designed once Phases 12-22 (web-side cleanup + hardening + - redesign) are done. + mobile-friendly endpoints. To be designed once Phases 12-23 (web-side cleanup + hardening, + redesign, and remote portal) are done. ## Working Notes / Environment Gotchas diff --git a/readme.md b/readme.md index 29734ad..1be2f75 100644 --- a/readme.md +++ b/readme.md @@ -114,6 +114,8 @@ partition, and clean shutdown still needs delayed-power or ignition-sense hardwa The browser-based phone relay was removed after real-world testing confirmed that mobile browsers cannot reliably use the Pi's WiFi and cellular data simultaneously. A native Android companion is -planned later instead. The next roadmap work is settings, followed by a final UI polish pass. Full -phase history, verification notes, and current scope live in +planned later instead. The next roadmap work is settings, followed by a final UI polish pass. +After the redesign, the same interface will become a secure remote trip portal backed by the +self-hosted server, with clear Local Pi/Remote Server labeling. Full phase history, verification +notes, and current scope live in [PLAN.md](./PLAN.md).