Tracking issue to evaluate / align JSS with the server-managed Type Index just proposed for the LWS Discovery spec.
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.
Tracking issue to evaluate / align JSS with the server-managed Type Index just proposed for the LWS Discovery spec.
add Type Index Section, open)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:
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.?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.Linkheaders; syntheticContainerPage).How this differs from JSS today
JSS currently follows the classic client-maintained TypeIndex (a
publicTypeIndexRDF doc ofsolid:TypeRegistrationthe client reads/writes). Note #215 already removes auto-creatingpreferences/typeIndexat 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)
TypeIndexService/TypeSearchServiceentries in the storage description.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 overtype(+ optionally other descriptive relations), returning a paginatedContainerPageof{id,type}items, auth-filtered.Consumer interest
The
solid-appsdesktops + hub panes would useTypeSearchServicefor "open allschema:Event" type queries (today they walk containers). Forward-compat we can adopt now on the client side: emitLink: <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.