On each page load, solid-client-authn silently retries prompt=none authorization with that dead clientid. Does UVDSL resolve the issue ?

[bourgeoa]

I would like to analyse the following comments related to pivot running https://solidcommunity.net server
Is the issue in Pivot or the web app like mashlib

from Jeff

I got 400s and then 429s going to my pod root. Claude tells me this might be impacting lots of users and a simple storage clear won't help: After solidcommunity.net dropped its dynamic OIDC client registrations (server restart or purge), every browser that had previously logged in to the databrowser was left with a stored clientid the server no longer knows. On each page load, solid-client-authn silently retries prompt=none authorization with that dead clientid, gets 400 "Unknown client", and keeps retrying — so affected users see their pods as broken, and the retry traffic lands on your rate limiter and turns into 429s. Recovery is harder than the error suggests: the "clear the local storage" hint fails most users because the stale entries live on the pod subdomain origin (e.g. jeff-zucker.solidcommunity.net) while the error page they're looking at is on solidcommunity.net. Workaround that works: open any non-HTML resource on the pod origin (e.g. /robots.txt), then clear the solidClientAuthenticationUser:, oidc., issuerConfig:* and solidClientAuthn:* localStorage keys from there and log in again. The root fix belongs upstream in solid-client-authn — on "Unknown client" it should discard the stored registration and re-register instead of looping.

from alastair

for this reason I have a shortcut ?reset=true in my local app which when added to the url will clear storage before trying to log in
I agree that having this in the client before the redirect would be nice

[bourgeoa]

Confirmed: solid-logic is on staging with @uvdsl/solid-oidc-client-browser ^0.2.3. Here's the detailed map of where each piece of the problem lives, based on the actual code.

Where the issues are

1. Trigger — CSS server (solidcommunity.net), not Pivot/mashlib

Community Solid Server keeps dynamic OIDC client registrations in a store that is not persisted across restarts by default. After a restart/purge, every previously handed-out client_id is unknown. This is the event that starts everything, and it's server-side — no client library change can prevent a server from forgetting registrations.

2. The retry loop — inrupt solid-client-authn-browser (upstream bug)

This is the "root fix belongs upstream" part of the comment. inrupt's restore flow (restorePreviousSession / handleIncomingRedirect) does a silent prompt=none authorization redirect to the IdP using the stored dynamic client_id. On 400 "Unknown client" it keeps retrying, and that retry traffic is what becomes 429s. The stored registration lives in localStorage, is never invalidated on "Unknown client", and is never re-registered automatically.

3. Amplifier — mashlib / solid-logic / solid-ui (app layer)

solid-ui calls authn.checkUser() on every page load (SolidAuth.ts, login.ts), which reaches SolidAuthnLogic.resolveCurrentUser() → handleIncomingRedirect({ restorePreviousSession: true }). There's no error branch that detects the stale-client state and breaks out. So the app re-triggers the library's loop on every load.

4. UX trap — origin-scoped storage

The stale entries live on the pod subdomain origin, while the error page is on the app origin. That's browser storage partitioning, not a code bug — it just makes the "clear storage" hint fail.

Will mashlib with UVDSL solve it?

Largely yes — the loop disappears at the client layer. The uvdsl client is structurally different:

• Restore = refresh-token grant, not a prompt=none redirect. SessionCore.restore() calls renewTokens() → requestFreshTokens(refresh_token, client_id, token_endpoint, key_pair) — a single POST to the token endpoint. There is no redirect to the IdP authorization endpoint at all in restore, so the "silent prompt=none with dead client_id" loop cannot happen.
• Fails once, no retry. On error, restore rejects with "No session to restore." (when not active). SolidAuthnLogic.resolveCurrentUser() explicitly catches /no session to restore/i and treats it as a normal first load. Result: one failed attempt per page load, session simply not restored — no 400 storm, no 429 storm.
• Next login self-heals. In redirectForLogin(), when no client_id is given, uvdsl does a fresh dynamic registration and stores the client_id in sessionStorage (tab-scoped, not localStorage). So the next explicit login gets a brand-new client and works again.

What UVDSL does NOT fix (remaining gaps)

1. Server-side trigger stays. CSS/solidcommunity.net still loses registrations on restart. The proper operator fix: persist CSS registrations, or use a static / dereferencable client_id (uvdsl explicitly supports "Clients with provided client_id"). That eliminates the whole class.
2. Stale IndexedDB isn't auto-cleared on invalid_client. uvdsl throws and rejects but leaves the dead client_id/refresh_token in the soidc IndexedDB. Each page load = one extra token-endpoint 400 until the user re-logs-in. Not a loop, but a small hardening opportunity: clear the session DB when the refresh grant returns invalid_client. That's a candidate for a solid-logic checkUser error branch or a uvdsl upstream change.
3. Storage-origin UX trap remains — but with uvdsl the symptom degrades to "just log in again", not "pod broken".
4. Deployment caveat. Whether the mashlib actually served by solidcommunity.net bundles uvdsl depends on it being rebuilt from the staging solid-logic. The old published bundle's nested copy still pins inrupt 1.17 — that's a stale build artifact, replaced when mashlib is rebuilt.

Bottom line

Layer	Issue	Fixed by UVDSL?
CSS server	registration loss + rate limit	❌ (needs persisted/static client)
inrupt client	prompt=none retry loop	✅ (uvdsl has no such loop)
mashlib/solid-logic/solid-ui	auto-restore amplification	✅ (fail-once + no-session handled)
storage origin	recovery UX	⚠️ (better symptom, same origin trap)

So: the loop itself is an inrupt client bug amplified by mashlib's auto-restore, triggered by CSS registration loss. Moving mashlib to the uvdsl-based solid-logic (staging) removes the loop at the client layer; the remaining must-fix for solidcommunity.net is server-side (persist registrations or use a static client_id). If you want, I can draft the optional hardening — clear the stale uvdsl session DB on invalid_client in SolidAuthnLogic.resolveCurrentUser().