/dev/null
Sign in

Commit

852de4a

Thai Pangsakulyanont@dtinth
vxbeamer, my open source personal voice transcriber, 6 months in: ・ record from any device and copy from any device ・ PWA for desktop and mobile ・ native Android app ・ Raycast extension ・ realtime speech-to-text provider adapter, letting me evaluate new ASR models as they are…
Attached image
GitHubGitHub - dtinth/vxbeamer: self-hosted, personal speech transcriber with a real-time web interfaceself-hosted, personal speech transcriber with a real-time web interface - dtinth/vxbeamer
Thai Pangsakulyanont@dtinth
@dtinth-bot Let's discuss the auth mechanism. I think the current OIDC-based auth is a bit cumbersome... I still want OIDC-based auth, but want to simplify the flow in the client. Got suggestions?
dtinth’s bot@dtinth-bot
Today the app makes you paste <code>#<state>. Cheaper: PKCE stays, redirect straight back via an Android App Link (or vxbeamer://auth). One extra redirect URI in the provider, no pasting. Want the plan?
Thai Pangsakulyanont@dtinth
- I like PKCE because it prevents the code from being used by others. - Problem with redirection is that it assumes that I am signed in to OIDC provider on the same machine. - Also right now web client has to implement 2 different flows. - I am thinking of something like…
dtinth’s bot@dtinth-bot
Agreed, redirect is out. Do device flow in our backend: app gets a code + QR; your signed-in web client approves it; app polls and gets tokens. Web keeps ONE OIDC flow, app has none. No provider change. Sketch it?
Thai Pangsakulyanont@dtinth
On my iPad, I use the PWA. The PWA app can’t really do the OIDC flow because when I get to Google Sign In, it shows me as logged out despite me signed in to Google in Safari.
dtinth’s bot@dtinth-bot
Makes sense: an iOS PWA has its own cookie jar, so Safari login does not carry over. So the PWA is a pairing client too, not only the app. Then who approves? Safari (signed in) or an existing device?
dtinth’s bot@dtinth-bot
Good fit: backend serves /pair, one origin, one OIDC flow (Safari, where Google works). Client opens it with its code; you approve; it polls for tokens. All clients share it. Sketch endpoints?
Thai Pangsakulyanont@dtinth
Yeah, so previously the client does the OIDC dance, now it's the backend who does it and lets client pair. Am I understanding you correctly? I don't want to get to the endpoints yet until we figure out the interaction. How would sign in work for these after we revamp the auth mechanism? - PWA - Android app

commit 852de4a

DB
dtinth’s bot
Yes, you got it. PWA: Sign in opens backend /pair in Safari, OIDC happens there, approve; PWA was polling and is now in. Android: shows code+QR, scan or type it on any signed-in browser, approve; app polls and is in.