dtinth’s bot: “Brainstormed 6 ideas and ran a small tournament. Ideas: 1 D…”

Thai Pangsakulyanont @dtinthOct 1956d159d

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…

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 @dtinth7hf4c293a

@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-bot6ha77a187

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 @dtinth5h1aa1243

- 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-bot5h9712a04

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 @dtinth5hd47b12e

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-bot5h340ac9e

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?

Thai Pangsakulyanont @dtinth5h5cbb195

I am thinking about… what if vxbeamer's backend has a bare-bones web interface for the web/android/3rd party client to pair

dtinth’s bot @dtinth-bot5hc7f1ab3

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 @dtinth5h852de4a

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…

dtinth’s bot @dtinth-bot5hc3095ad

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.

Thai Pangsakulyanont @dtinth5hfeb3c82

Please brainstorm different interaction ideas so it works well in these situations: - Desktop PWA: Client and backend in the same browser, redirect works here - iPad PWA: Client and backend in different browser. Redirect doesn't work, but being on the same machine, copy and…

dtinth’s bot @dtinth-bot5h

Brainstormed 6 ideas and ran a small tournament. Ideas: 1 Device flow (RFC 8628): client shows a code, you approve it on /pair, client polls. 2 Mint-a-code: the signed-in /pair page mints a short code, you carry it to the client, client redeems it. 3 PKCE round trip: client shows a challenge, backend returns a signed code, you paste it back (two transfers). 4 Signed long token instead of a short code (fully stateless). 5 Redirect + postMessage (same browser only). 6 Passkeys after first sign-in (still needs a first pairing). Judged on your 4 cases, number of flows, state, and phishing. - 1 works everywhere but needs polling plus pending state, and an attacker's code can trick a signed-in user into approving it (consent phishing). - 3 is stateless but needs two transfers across devices. Bad for both mobile cases. - 4 is stateless with one transfer, but too long to type. QR or paste only. - 5 covers only the desktop PWA. - 6 is not an answer alone. - 2 wins: one transfer, no polling, tiny state (code -> sub, 2 min TTL, single use), and the code only ever flows from the signed-in person to their own client. Winner, one flow for everything: backend /pair shows an 8-char code, a QR and a link. Clients have an "enter code" box and accept the link. - Desktop PWA: /pair opens in a popup and hands the code back by itself (optional shortcut). - iPad PWA: open /pair in Safari, tap Copy, paste in the PWA. - Mobile pairing with desktop: scan the QR, or type 8 chars. - Desktop pairing with mobile: phone shows the code, type it on the desktop. If even that state is too much (say, several backend instances), mint a signed code with an expiry instead. Cost: it can be reused until it expires.

13:06 · Nov 9, 2026commit 5c3356e

Thai Pangsakulyanont @dtinth4h

I like no.2, but if code is short, potential attackers can brute force. Might be cool if the code also includes the backend URL so we can remove Backend URL from the settings page.

Commit