Tracking issue to evaluate / align JSS with the server-managed Type Index just proposed for the LWS Discovery spec.

• PR: add Type Index Section w3c/lws-protocol#115 (add Type Index Section, open)
• Preview: https://pr-preview.s3.amazonaws.com/w3c/lws-protocol/pull/115.html
• Cites the classic type-indexes as reference, but reimagines it as a server feature.

What it proposes

Two server-managed services advertised in the storage description:

• TypeIndexService (GET) — paginated list of the distinct types present in the storage that the authenticated user is authorized to see. No query params.
• TypeSearchService (GET/POST) — returns the resource URIs matching a type query.

Key properties:

• Server-populated, not client-written (clients can't corrupt it). Types derived from Link rel="type" headers at write time + server-intrinsic LWS classes (lws#Container, lws#DataResource); servers MAY also parse content but are not required to.
• Conjunctive-normal-form queries: ?type=A,B&type=C = (A OR B) AND C (comma = OR, repeat = AND). MAY also filter by other descriptive link relations (relation name as the param), same CNF semantics; the indexed relation set is deliberately not enumerated (no discovery oracle). No nesting/negation/ordering/text.
• Authorization-filtered results; auth filtering is strict (not subject to the eventual-consistency allowance).
• Pagination reuses the container model (page URIs in Link headers; synthetic ContainerPage).
• Type/relation membership MAY be eventually consistent after writes (no read-your-writes).

How this differs from JSS today

JSS currently follows the classic client-maintained TypeIndex (a publicTypeIndex RDF doc of solid:TypeRegistration the client reads/writes). Note #215 already removes auto-creating preferences/typeIndex at pod creation — so dropping the client-doc-by-default is consistent with moving toward a server-managed index.

The LWS model is the opposite end: the server indexes by type (from Link rel=type + intrinsic state) and answers queries returning actual URIs, auth-filtered. So it's a new server capability, not a tweak to the existing doc handling.

Implementation sketch (when/if we align)

• Advertise TypeIndexService / TypeSearchService entries in the storage description.
• On write (PUT/POST/PATCH), capture Link; rel="type" headers + intrinsic class; maintain a per-storage index (type -> resource URIs).
• GET index -> paginated distinct types (auth-filtered).
• GET/POST search -> CNF filter over type (+ optionally other descriptive relations), returning a paginated ContainerPage of {id,type} items, auth-filtered.
• Reuse existing container pagination; allow bounded eventual consistency on derivation only.

Consumer interest

The solid-apps desktops + hub panes would use TypeSearchService for "open all schema:Event" type queries (today they walk containers). Forward-compat we can adopt now on the client side: emit Link: <type>; rel="type" on writes so resources become indexable the moment a server implements this (servers ignore unknown Link rels).

Status

Open PR, not merged, may change — this is align-when-it-stabilizes tracking, not an immediate ask. Related LWS-alignment issues: #87, #89, #319, #386, #215.