Background
The `/idp` landing page added in #287 (PR-A) shows this sign-in note for users who already have an account:
Already have an account? Sign in from inside the Solid app you want to use — the app will redirect here when authentication is needed.
Honest about today's capabilities (no standalone `/idp/login` yet — that's PR-B), but vague. A first-time user reads it and thinks: which app?
Proposal
Name pilot explicitly as the recommended example client. It lives at a stable `gh-pages` URL, requires zero install, and demonstrates the full JSS+pilot+LOSOS stack end-to-end. Concrete onramp without locking JSS to any one client.
Approximate copy:
Already have an account? Sign in from a Solid app — for example, pilot is a minimal console you can open right now. Point it at this server and click Sign In.
Why pilot, and not mashlib
Different roles:
- mashlib is the data browser auto-injected on raw pod resources via `--mashlib-module`. It's always-there plumbing — anyone hitting a resource URL already sees it. It doesn't need calling out on the landing.
- pilot is a focused console — Profile, Tasks via TypeIndex, Settings. A way better first impression than landing in the mashlib outliner. It's the kind of thing you'd send a brand-new user to.
Both have a place; the landing should name the inviting one.
Non-goals
- Bundling pilot with JSS. Just a link.
- Removing or rewording mashlib injection. Unrelated.
- Making the landing a directory of every Solid app. One named example is enough; alternatives can be discovered separately.
Risk
Coupling the landing's link to `solid-apps.github.io/pilot`'s `gh-pages` URL. If pilot ever breaks against new JSS, the landing's link looks bad. Mitigation: pilot's `gh-pages` is already where we deploy from, treating it as the reference client is fine — and a broken pilot is a Day-One thing to fix anyway.
Scope
~5 lines in `landingPage()` (`src/idp/views.js`). Optional: tiny CSS bump to make the app name a styled link rather than inline. Test update: assert the landing body contains the pilot URL.
Trivially small PR. Mostly editorial.
Background
The `/idp` landing page added in #287 (PR-A) shows this sign-in note for users who already have an account:
Honest about today's capabilities (no standalone `/idp/login` yet — that's PR-B), but vague. A first-time user reads it and thinks: which app?
Proposal
Name pilot explicitly as the recommended example client. It lives at a stable `gh-pages` URL, requires zero install, and demonstrates the full JSS+pilot+LOSOS stack end-to-end. Concrete onramp without locking JSS to any one client.
Approximate copy:
Why pilot, and not mashlib
Different roles:
Both have a place; the landing should name the inviting one.
Non-goals
Risk
Coupling the landing's link to `solid-apps.github.io/pilot`'s `gh-pages` URL. If pilot ever breaks against new JSS, the landing's link looks bad. Mitigation: pilot's `gh-pages` is already where we deploy from, treating it as the reference client is fine — and a broken pilot is a Day-One thing to fix anyway.
Scope
~5 lines in `landingPage()` (`src/idp/views.js`). Optional: tiny CSS bump to make the app name a styled link rather than inline. Test update: assert the landing body contains the pilot URL.
Trivially small PR. Mostly editorial.