whereis.dieu.dev: decide requester auth/identity approach

[jonathandieu]

Concept: replace Find My iPhone with a service where someone requests my location
(e.g. navigating to whereis.dieu.dev), I get an approve/deny prompt on my phone, and
only send location if I approve. Every request, decision, and location shared gets
logged as an auditable trail.

Open question, deliberately not decided yet: how does the requester prove who they
are, and what's the actual login/request UX for them.

Options considered:

• Cloudflare Access (email OTP or IdP) gating the app. Zero auth code, centrally
  revocable, built-in audit log, persistent session after first login. Tradeoff: the
  first-login screen is Cloudflare-branded, not a custom UX, and gating is per-path
  if a public landing page should stay ungated.
• Personalized magic links, one static token per person, no login screen. Lowest
  friction, feels most like a custom app. Tradeoff: the token is the identity, so a
  leaked link means someone else's identity with no recourse unless revocation/rotation
  is built by hand.
• Telegram bot instead of a web app. Identity is free (Telegram already knows who's
  messaging), inline-keyboard approve/deny, native live-location sharing UI already
  exists. Tradeoff: not a branded whereis.dieu.dev experience, depends on Telegram as
  a platform.
• Route requesters over Tailscale (reusing Cross-cluster networking for unified Grafana + cost dashboard #15's investment). Strong identity, no
  public exposure. Tradeoff: asking non-technical family to install/maintain a VPN
  app is a big UX cost for this audience — probably fine for cluster-to-cluster
  traffic, likely wrong here.
• Passkeys/WebAuthn. Modern, phishing-resistant. Tradeoff: per-person enrollment has
  a bootstrapping problem (need an authenticated step to register the passkey first),
  likely overkill for a handful of trusted people.

On the approval side (regardless of auth choice): the phone notification needs to show
who's asking and when, pending requests need a timeout/auto-expiry so the audit log
doesn't fill with permanently-pending rows, and location capture should be point-in-time
(browser Geolocation API on approval) rather than continuous background tracking.

Not started. Revisit in a future session before locking in an approach.

[jonathandieu]

Decisions from further discussion:

• Repo structure: own repo (jonathandieu/whereis) with its own CI building
  ghcr.io/jonathandieu/whereis, same shape as portfolio/overengineered/api.
  dieubernetes only gets a thin charts/workloads/whereis/ chart referencing that
  image, no app source here.
• Push mechanism: ntfy, self-hosted. Confirmed via search to be a real, widely-used
  self-hosted push tool (not something to build from scratch).
• Scope for v1: point-in-time location only, with a fun/custom web view for the
  requester. Continuous/session-based tracking explicitly deferred.
• Continuous tracking, if ever revisited: confirmed via research that iOS
  backgrounding makes this a native-app problem (CLLocationManager +
  allowsBackgroundLocationUpdates + Always permission), not a web/PWA one — Safari
  and PWAs get suspended once backgrounded, so true continuous sharing needs a real
  iOS app, sideloadable for personal use without App Store review. Hauk
  (https://github.com/bilde2910/Hauk) already does session-based continuous sharing
  open-source and would be a closer starting point than extending the point-in-time
  design, if this gets picked up later. A PWA using watchPosition() covers
  foreground-only continuous sharing (breaks on screen lock) as a lighter middle
  ground if full background tracking isn't worth the native-app cost.

Requester auth/identity approach (Cloudflare Access vs personalized links vs Telegram
bot vs Tailscale vs passkeys) is still the one open question, per the issue body.