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