Discovery: saved filters as reusable "interests" to surface matching events and communities

[hhkaos]

Context

Follow-up from a UX discussion about event discovery: could saved filters double as "interests/preferences" — reusable not just to filter your own subscribed feeds, but to check against adopters.json and surface matching events (beyond your subscriptions) and matching communities?

Current state

• state.savedFilters already exists in the app state (app.js:29, defaulted at app.js:96) but is dead code — nothing reads or writes it beyond initialization. There's no save/apply UI for it today.
• Boards (state.boards) already implement the closest working pattern: named, saved chips rendered in the sidebar (saved-filter / saved-row classes, see renderBoards() around app.js:1032) that set the active source on click. A "saved filter" feature would look and behave very similarly.
• filteredEvents() (app.js:368) only ever evaluates sourceEvents(), which is scoped to subscribed feeds (app.js:355-360). Events from feeds you haven't subscribed to are never fetched or evaluated.
• adopters.json (fetched from ADOPTERS_URL, app.js:10) is a flat community catalog: name, url, feed, logo, desc {en, es}. No per-community metadata for topic, language, mode, or location — and currently only one entry. It's used today only to list/subscribe-unsubscribe feeds in the Sources modal (renderSources(), app.js:1737), never evaluated against event-level filters.

Proposal, split by cost

1. Save filters as named "interests" — cheap, self-contained.
Give the existing (currently unused) state.savedFilters a UI: name the current filter combination, show it as a chip in the sidebar (reusing the boards visual/interaction pattern), click to apply. No new data sources needed.

2. Use interests to discover matching events from feeds you're not subscribed to — valuable, but an architecture change.
Today nothing fetches events from a feed until you subscribe to it. Matching interests against the wider catalog means fetching adopter feeds you haven't subscribed to, on demand. Fine for a catalog of 1; doesn't scale client-side as the catalog grows (fetching N feeds on every exploration action). Should be an explicit, user-initiated "explore" action (not automatic/background) with aggressive caching — not a live filter.

3. Use interests to discover matching communities — blocked on data, not code.
adopters.json has no topic/language/location metadata per community — only name/url/feed/desc. The only way to infer a "community match" today is to fetch that community's feed and check whether any of its events match (same cost/scope as #2), which really answers "does this feed have a matching event" rather than "is this community relevant to me." A real community-level match needs the catalog schema itself to carry topic/location/language metadata, which is outside this repo (OpenTechEvents catalog/spec, not ote-reader).

Suggested order

1. Ship saved filters/interests (Add URL parameter to easily subcribe to a feed #1) — low risk, reuses existing patterns.
2. Add an explicit "explore new feeds matching my interests" action (Add multi-language support to the UI #2) — manual trigger, cached, not automatic.
3. Revisit community-level matching (Mechanism similar to OPML Export/import #3) once/if the adopters catalog gains richer metadata upstream.

No implementation planned yet — this issue is to capture the discussion and the architectural constraints before any of this gets scoped.