Context

jspod ships Pilot bundled at `/public/apps/pilot/` and is about to gain a `jspod install ` command to install arbitrary Solid apps into the pod's `public/apps/` tree. This is purely a wrapper-side convention today — no JSS-side support is needed for it to work.

But there's an open architectural question worth raising: should the Solid pod itself know what apps are installed in it?

Problem

If apps live in pods (as Solid's "apps consume data from pods" pattern suggests), and a user can have many apps installed, there's no standard way today to:

• Discover which apps a pod has installed (without listing `/public/apps/` and inspecting each directory)
• Surface them to clients (an SDK or another app that wants to know "what apps does this user already have?")
• Update / remove them in a protocol-aware way
• Link an app to its data location (Type Index works for data shape → container, but not for app identity → app code location)

Today this is implicit and convention-based. A more principled design might give it a Solid-native shape.

Proposed primitives to consider

Option A: `/.well-known/apps` endpoint

A read-only listing of installed apps, owner-only or public-read per ACL. JSON-LD with one entry per app, including manifest fields (name, description, version, homepage). jspod's install command would write to the underlying directory and JSS would surface the listing.

Pro: minimal change, just a read surface. Pro: discoverable via HTTP GET.
Con: another endpoint to maintain.

Option B: An App Index (analogous to Type Index)

A Solid-native registry resource (e.g. `/settings/appIndex.jsonld`) that maps WebID-relative app identifiers to their pod-local install paths. Apps register themselves via PUT, similar to how the Type Index works for data containers.

Pro: composable with the existing Type Index pattern. Pro: works across implementations (CSS, NSS, JSS) if the format is shared. Pro: clients can ask "is X installed?" via a single resource read.
Con: needs a spec / community sign-off if it's going to be portable.

Option C: A read-only "apps" view derived from filesystem

JSS provides a virtual `/.well-known/apps` (or `/apps` resource) that's lazily computed by scanning `/public/apps/*/manifest.json`. No persistent index file; just a server-side aggregation.

Pro: zero state to keep in sync. Pro: drop-in works for anyone using the directory convention.
Con: scans on every request (or needs caching).

Recommendation

Start with Option C, as a low-cost validation that the convention is useful. If client adoption justifies it, graduate to Option B with a written-out Type-Index-style spec.

Cross-references

• jspod#24 — jspod-side install command
• JSS#462 — onboarding overhaul (this would be a candidate Phase 8)
• The Solid Type Index spec — pattern this could parallel