/dev/null
Sign in

Commit

c7f1ab3

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?

commit c7f1ab3

TP
Thai Pangsakulyanont
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…