Background
`registerPage` in `src/idp/views.js` is a functional signup form but has rough edges for first-time users. Looking at it fresh today:
- Username regex `^[a-z0-9]+$`, min 3 chars → rules out common shapes like `alice-smith`, `alice.smith`, `alice_work`. No Unicode either.
- No WebID preview. The user submits without seeing that they're about to get e.g. `https://jss.live/alice/profile/card.jsonld#me\`.
- Two-step post-submit: success banner says "you can now sign in" and bounces to `/idp/auth`. A freshly-created account doesn't get an auto-login.
- Page styling is bare compared to our other surfaces.
Proposed scope
Explicitly leaving email / account recovery out of this issue — that's a bigger design discussion.
1. Relax username validation.
`^[a-z0-9][a-z0-9._-]{1,30}[a-z0-9]$` — must start and end alphanumeric, can contain dot, dash, underscore in the middle. Keep 3-char minimum. Blocks `.hidden`, trailing `.`, and double-separators like `--` if desired (extra check).
2. Live WebID preview.
As the user types, show the resolved WebID:
```
WebID: https://jss.live/alice/profile/card.jsonld#me
Storage: https://jss.live/alice/
```
Pure client-side — template the origin + path mode into the page. Subdomain mode renders the subdomain shape. This converts an abstract form into a concrete "here's what you're about to get".
3. Auto-login on successful register.
Instead of "Account created — now go sign in", issue the token and redirect to the original `uid` interaction (or `/idp/auth`) with the session primed. Matches the pod-creation token flow that `POST /.pods` already supports.
4. (optional) Visual pass.
Bring the register card up to the same gradient-accent feel as pilot's Onboarding, so the first screen a new user sees doesn't feel half-finished. Keep the same `styles` constant but add a subtle header gradient + larger logo treatment. Low effort if bundled with the above.
Non-goals
- Email / account recovery. Separate discussion.
- Passkey-first signup. Passkey prompt already exists post-login (`passkeyPromptPage`); leave that flow alone.
- WebAuthn at register time. Out of scope.
Back-compat
- The new username regex is a superset of the current one, so no existing user is invalidated.
- Auto-login changes the response shape of `POST /idp/register` slightly (redirect instead of success page). If any script depended on the success HTML, they'd need an update — unlikely given this is a UI endpoint.
Happy to PR.
Background
`registerPage` in `src/idp/views.js` is a functional signup form but has rough edges for first-time users. Looking at it fresh today:
Proposed scope
Explicitly leaving email / account recovery out of this issue — that's a bigger design discussion.
1. Relax username validation.
`^[a-z0-9][a-z0-9._-]{1,30}[a-z0-9]$` — must start and end alphanumeric, can contain dot, dash, underscore in the middle. Keep 3-char minimum. Blocks `.hidden`, trailing `.`, and double-separators like `--` if desired (extra check).
2. Live WebID preview.
As the user types, show the resolved WebID:
```
WebID: https://jss.live/alice/profile/card.jsonld#me
Storage: https://jss.live/alice/
```
Pure client-side — template the origin + path mode into the page. Subdomain mode renders the subdomain shape. This converts an abstract form into a concrete "here's what you're about to get".
3. Auto-login on successful register.
Instead of "Account created — now go sign in", issue the token and redirect to the original `uid` interaction (or `/idp/auth`) with the session primed. Matches the pod-creation token flow that `POST /.pods` already supports.
4. (optional) Visual pass.
Bring the register card up to the same gradient-accent feel as pilot's Onboarding, so the first screen a new user sees doesn't feel half-finished. Keep the same `styles` constant but add a subtle header gradient + larger logo treatment. Low effort if bundled with the above.
Non-goals
Back-compat
Happy to PR.