Context
Follow-up to JSS#463 (Solid-native apps-in-pods surface). jspod#25 proposes `jspod install ` — clone a Solid app's repo into the pod's `public/apps//` directory.
The wrapper-side install command works without any JSS support. But there's an open question about whether JSS itself should know about git as an app source — and if so, what the surface looks like.
Why bring git into the protocol conversation
Most Solid apps live in git. The Type Index pattern names data containers; an analogous "apps live here, here's where their source is" pattern would let:
- A pod owner reproducibly re-install apps after a wipe ("install everything I had before")
- Cross-server migration ("export pod, on the other server reinstall all apps from their git URLs")
- App authors publish a single canonical URL that any JSS deployment can install from
- Discovery: a Solid client could ask "what apps does this pod have, and where are their sources?"
Proposed shapes
Option A: git source recorded only in app manifests (no JSS-side change)
`pod-data/public/apps//manifest.json` includes a `source: { type: "git", url, ref }` block. The wrapper that did the install writes it; JSS is unaware. Reads / migrations are wrapper concerns.
Pro: simplest, no JSS change.
Con: no protocol-level discovery; clients have to enumerate the directory and parse manifests.
Option B: `/.well-known/apps` aggregates manifests including source URLs
JSS reads each `apps/*/manifest.json` and serves an aggregated JSON-LD listing. App entries include the git source if present. Same primitive as Option C in JSS#463, but with git URLs visible in the API.
Pro: discoverable. Pro: one read for a client to find "all apps + their sources."
Con: more endpoint surface.
Option C: An "App Index" Solid resource
Analogous to the Type Index. `/settings/appIndex.jsonld` lists installed apps with their pod-local install path + their original source URL (git, tarball, npm). Apps register themselves on install via PUT.
Pro: Solid-native, composable with the Type Index spirit.
Con: needs a spec or community sign-off if it's to be portable across CSS / NSS / JSS.
Recommendation
Option A short-term (wrapper-side, no JSS change). If jspod#25 ships and the manifest convention catches on, graduate to Option B as a low-cost validation that the data is useful to clients. Option C is the long-arc design once enough apps are doing this.
Cross-references
- jspod#24, jspod#25 — wrapper-side install command (the generalized version + the git-focused subset)
- JSS#462 — onboarding overhaul (apps-in-pods is implicit Phase 8)
- JSS#463 — broader protocol-level apps surface (this is the git-focused subset)
- Solid Type Index spec — analogue
Context
Follow-up to JSS#463 (Solid-native apps-in-pods surface). jspod#25 proposes `jspod install ` — clone a Solid app's repo into the pod's `public/apps//` directory.
The wrapper-side install command works without any JSS support. But there's an open question about whether JSS itself should know about git as an app source — and if so, what the surface looks like.
Why bring git into the protocol conversation
Most Solid apps live in git. The Type Index pattern names data containers; an analogous "apps live here, here's where their source is" pattern would let:
Proposed shapes
Option A: git source recorded only in app manifests (no JSS-side change)
`pod-data/public/apps//manifest.json` includes a `source: { type: "git", url, ref }` block. The wrapper that did the install writes it; JSS is unaware. Reads / migrations are wrapper concerns.
Pro: simplest, no JSS change.
Con: no protocol-level discovery; clients have to enumerate the directory and parse manifests.
Option B: `/.well-known/apps` aggregates manifests including source URLs
JSS reads each `apps/*/manifest.json` and serves an aggregated JSON-LD listing. App entries include the git source if present. Same primitive as Option C in JSS#463, but with git URLs visible in the API.
Pro: discoverable. Pro: one read for a client to find "all apps + their sources."
Con: more endpoint surface.
Option C: An "App Index" Solid resource
Analogous to the Type Index. `/settings/appIndex.jsonld` lists installed apps with their pod-local install path + their original source URL (git, tarball, npm). Apps register themselves on install via PUT.
Pro: Solid-native, composable with the Type Index spirit.
Con: needs a spec or community sign-off if it's to be portable across CSS / NSS / JSS.
Recommendation
Option A short-term (wrapper-side, no JSS change). If jspod#25 ships and the manifest convention catches on, graduate to Option B as a low-cost validation that the data is useful to clients. Option C is the long-arc design once enough apps are doing this.
Cross-references