edufeed/edufeed-app

Watch

Fork 0

Ext facet search is unreachable end-to-end: no published form declares an ext field, and facet hits are intersected with community-shared items #59

New issue

Open

opened 2026-07-30 10:35:32 +00:00 by laoc · 0 comments

laoc commented

2026-07-30 10:35:32 +00:00

Owner

Found while browser-verifying #58 (@TestOER), then re-verified independently. #58 fixed the filter key; this issue is about the fact that no user can currently reach that filter, and about one product decision that blocks it even once they can.

1. No published form declares an `output: ext` field

The facet section in LearningContentFilters.svelte only renders when extFieldDefs is non-empty, which requires the community's preferred kind-30168 form to have at least one field with output: ext.

Measured against wss://relay.edufeed.org (TestOER also checked amb-relay, oersi, relay-rpi):

kind-10222 communities                       59
  ... referencing a form at all               2   (30168:d41b2289:g, 30168:776c7bfe:membership)
kind-30168 forms                             18
  ... with any field-output tag                3   (amb-basic 6, testantrag 3, and 0 elsewhere)
  ... with a field-output of 'ext'             0

So extFieldDefs is empty for every deployed community and the facet chips never render.

2. The corpus that does carry ext tags has no published form

The ~6280 kind-30142 resources on amb-relay include conformant tags — ext:ekw:schoolType:id, ext:ekw:method:id, ext:ekw:gradeLevel:id, alongside ["l","ekw","metadata-form"]. But no d=ekw kind-30168 form exists on any relay checked. Those events come from an external pipeline that writes ext tags without publishing the form that would let the UI discover them as facets.

So the two halves never meet: the form-driven UI has no ext fields, and the ext-tagged data has no form.

Also worth recording for anyone writing these filters: the values are nostr:39738:<pubkey>:<slug> addresses, not w3id URIs. Querying the plausible-looking https://w3id.org/kim/schularten/gymnasium returns 0 and looks exactly like a regression.

3. Decision needed: facet hits are intersected with the community's own shared items

LearningView.svelte:130:

return accessFilteredItems.filter((item) => nip50ResultIds.has(item.id));

The rendered list is the intersection of the community's shared resources with the search hits. Verified in a browser: with a correct filter key returning 5 matching events from the relay, the view still showed "No results", because those 5 resources are in no community's shared list.

That is defensible (a community view showing only that community's material) but it means facet search can never surface a resource that has not been shared into the community, however well the tags match. Needs a product call:

(a) intersection is intended — then ext facets are only useful once ekw-style resources are shared into a community, and this issue's real fix is a data/import task, not a UI one; or
(b) facet search should query the wider corpus — then :130 needs to union rather than intersect, with an explicit "outside this community" affordance.

Suggested order

Answer (3) — it decides whether (1)/(2) are worth building.
If (a): publish an ekw form with output: ext fields whose d tag and field ids match the tags already in the corpus (ekw / schoolType), and share the resources into a community.
Either way, an end-to-end fixture would be worth having: today verifying facet search at all requires hand-authoring a form, a community and 19 vocab events on a local relay.

No code defect here — #58's fix is correct and merged at 3353662b. This is the gap between it and a user-visible feature.

Found while browser-verifying #58 (@TestOER), then re-verified independently. #58 fixed the *filter key*; this issue is about the fact that **no user can currently reach that filter**, and about one product decision that blocks it even once they can. ## 1. No published form declares an `output: ext` field The facet section in `LearningContentFilters.svelte` only renders when `extFieldDefs` is non-empty, which requires the community's preferred kind-30168 form to have at least one field with `output: ext`. Measured against `wss://relay.edufeed.org` (TestOER also checked `amb-relay`, `oersi`, `relay-rpi`): ``` kind-10222 communities 59 ... referencing a form at all 2 (30168:d41b2289:g, 30168:776c7bfe:membership) kind-30168 forms 18 ... with any field-output tag 3 (amb-basic 6, testantrag 3, and 0 elsewhere) ... with a field-output of 'ext' 0 ``` So `extFieldDefs` is empty for every deployed community and the facet chips never render. ## 2. The corpus that *does* carry ext tags has no published form The ~6280 kind-30142 resources on `amb-relay` include conformant tags — `ext:ekw:schoolType:id`, `ext:ekw:method:id`, `ext:ekw:gradeLevel:id`, alongside `["l","ekw","metadata-form"]`. But **no `d=ekw` kind-30168 form exists on any relay checked.** Those events come from an external pipeline that writes ext tags without publishing the form that would let the UI discover them as facets. So the two halves never meet: the form-driven UI has no ext fields, and the ext-tagged data has no form. **Also worth recording for anyone writing these filters:** the values are `nostr:39738:<pubkey>:<slug>` addresses, *not* w3id URIs. Querying the plausible-looking `https://w3id.org/kim/schularten/gymnasium` returns 0 and looks exactly like a regression. ## 3. Decision needed: facet hits are intersected with the community's own shared items `LearningView.svelte:130`: ```js return accessFilteredItems.filter((item) => nip50ResultIds.has(item.id)); ``` The rendered list is the intersection of the community's shared resources with the search hits. Verified in a browser: with a correct filter key returning 5 matching events from the relay, the view still showed "No results", because those 5 resources are in no community's shared list. That is defensible (a community view showing only that community's material) but it means **facet search can never surface a resource that has not been shared into the community**, however well the tags match. Needs a product call: - **(a)** intersection is intended — then ext facets are only useful once ekw-style resources are shared into a community, and this issue's real fix is a data/import task, not a UI one; or - **(b)** facet search should query the wider corpus — then `:130` needs to union rather than intersect, with an explicit "outside this community" affordance. ## Suggested order 1. Answer (3) — it decides whether (1)/(2) are worth building. 2. If (a): publish an `ekw` form with `output: ext` fields whose `d` tag and field ids match the tags already in the corpus (`ekw` / `schoolType`), and share the resources into a community. 3. Either way, an end-to-end fixture would be worth having: today verifying facet search at all requires hand-authoring a form, a community and 19 vocab events on a local relay. *No code defect here — #58's fix is correct and merged at `3353662b`. This is the gap between it and a user-visible feature.*

No labels

bug

discussion

enhancement

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

edufeed/edufeed-app#59

No description provided.

Rows
Columns

Ext facet search is unreachable end-to-end: no published form declares an ext field, and facet hits are intersected with community-shared items #59

1. No published form declares an output: ext field

2. The corpus that does carry ext tags has no published form

3. Decision needed: facet hits are intersected with the community's own shared items

Suggested order

1. No published form declares an `output: ext` field