Brummel/doctate
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

Watch-Pairing-Flow fuer Self-Service-Onboarding (statt API-Key im Build) #5

New Issue
Open
opened 2026-05-20 16:42:45 +02:00 by Brummel · 0 comments
Brummel commented 2026-05-20 16:42:45 +02:00
Owner
Copy Link
Copy Source

Strategische Antwort auf das 1-APK-pro-User-Modell

Heute ist BuildConfig.API_KEY eine String-Konstante in der APK. Jeder neue Tester = ein dedizierter Build + physischer Pairing-Termin. Skaliert nicht über ~2–3 Tester.

Vorgeschlagenes Modell

  1. Watch zeigt beim Erst-Start einen 6-stelligen Code (Random, ≤5 min gültig).
  2. User loggt sich in die Doctate-Web-UI ein und gibt den Code unter „Watch koppeln" ein.
  3. Server bindet den Code an den eingeloggten User-Slug und stellt einen frischen Device-API-Key aus.
  4. Watch speichert den Key in EncryptedSharedPreferences / DataStore (verschlüsselt mit Android Keystore).
  5. Eine generische APK pro Build reicht für alle Tester.

Implikationen

  • Server: neue Endpoints /api/pair/begin (Code → Pending-Pairing), /api/pair/confirm (Code + Session → Key ausstellen). Pending-Tabelle mit TTL.
  • Watch: Setup-Screen, DataStore-backed Settings-Impl (der Kommentar in clients/wearos/.../settings/Settings.kt:7 deutet das schon an), Pairing-UI.
  • Web-UI: Bestätigungsseite mit Code-Eingabe, im User-Settings-Bereich.
  • Migration: bestehende BuildConfig.API_KEY-APKs bleiben gültig (Fallback), neue APKs nutzen den Pairing-Pfad.

Wann sinnvoll

Ab ~3 Testern oder spätestens, wenn Tester ausserhalb des LAN/physischen Zugriffs onboarden sollen.

## Strategische Antwort auf das 1-APK-pro-User-Modell Heute ist `BuildConfig.API_KEY` eine String-Konstante in der APK. Jeder neue Tester = ein dedizierter Build + physischer Pairing-Termin. Skaliert nicht über ~2–3 Tester. ## Vorgeschlagenes Modell 1. Watch zeigt beim Erst-Start einen 6-stelligen Code (Random, ≤5 min gültig). 2. User loggt sich in die Doctate-Web-UI ein und gibt den Code unter „Watch koppeln" ein. 3. Server bindet den Code an den eingeloggten User-Slug und stellt einen frischen Device-API-Key aus. 4. Watch speichert den Key in `EncryptedSharedPreferences` / DataStore (verschlüsselt mit Android Keystore). 5. **Eine generische APK pro Build reicht für alle Tester.** ## Implikationen - **Server**: neue Endpoints `/api/pair/begin` (Code → Pending-Pairing), `/api/pair/confirm` (Code + Session → Key ausstellen). Pending-Tabelle mit TTL. - **Watch**: Setup-Screen, DataStore-backed `Settings`-Impl (der Kommentar in `clients/wearos/.../settings/Settings.kt:7` deutet das schon an), Pairing-UI. - **Web-UI**: Bestätigungsseite mit Code-Eingabe, im User-Settings-Bereich. - **Migration**: bestehende `BuildConfig.API_KEY`-APKs bleiben gültig (Fallback), neue APKs nutzen den Pairing-Pfad. ## Wann sinnvoll Ab ~3 Testern oder spätestens, wenn Tester ausserhalb des LAN/physischen Zugriffs onboarden sollen.
Brummel added the idea label 2026-05-20 16:42:45 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BLOCKER
Kernfunktionalitaet kaputt - preemptet jede andere Auswahl
 bug
Beobachtbares Fehlverhalten
 feature
Substantielle Erweiterung, kein voller Spec noetig
 idea
Kann gestrichen werden - kein Commitment
No Label idea
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude (Claude) Brummel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Brummel/doctate#5
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?