All feeds have the same limitation: they incorrectly assume past behavior is indicative of future intent. They drift toward what users have done than what they are after. Present intent is much more indicative but they have no clean way for the user to say what they want right now.

I maintain a reader-side map of the blyg network: a local crawler over the manifests, feeds and stub chains, with search and an activity view on top. The query is a declared present intent. The algorithm selects seeds from the locally maintained "atlas" by comparing cosine similarity of embeddings, then hops from seeds through the local map with weight decay based on hop count/edge type (and optionally recency), returns a pool of results, then locally reranks it to answer the query. To turn the query into a feed, all that has to be done is make the queries persistent and run them over what changed since the last time you looked.

Hoppers are also a signal, since creating and naming one states intent. But only collection activity reveals whether you mean it.

As far as I understand, you could have hoppers with queries attached and sort hand-selected content from standing query results into the hopper. This can then help you refine the query/intent, e.g. you can use the hopper items as new seeds for future searches under that query. Both the query declaration and hand-selection are intentional and kept as human processes; it's only the ranking that the machine infers.