Multi-value `#h` filters silently narrow to the lexicographically first channel, dropping all others

[redirwin]

Summary

A /query (or REQ) filter with multiple #h channel values — e.g.
{"kinds":[30620], "#h":[<id1>,<id2>,…]} — is silently answered as if it
named only ONE channel: the lexicographically smallest id. Events in every
other listed channel are never returned. No error or warning is surfaced.

Root cause

extract_channel_id_from_filter in crates/buzz-relay/src/handlers/req.rs
returns the first parseable UUID from the filter's #h values:

fn extract_channel_id_from_filter(filter: &Filter) -> Option<uuid::Uuid> {
    for (tag_key, tag_values) in filter.generic_tags.iter() {
        let key = tag_key.to_string();
        if key == "h" {
            for val in tag_values {
                if let Ok(id) = val.parse::<uuid::Uuid>() {
                    return Some(id);
                }
            }
        }
    }
    None
}

nostr::Filter stores generic_tags values in a sorted set, so "first" is
deterministically the smallest id. build_event_query_from_filter bakes that
single id into the SQL scope (filter_to_query_params(filter, channel_id, …)),
and the Rust post-filter afterwards can only REMOVE rows — it can never
restore the channels the SQL scope dropped.

The sibling helper extract_channel_id_from_filters (plural, same file)
shows the intended semantics: on multiple distinct channel ids it returns
None and falls back to global scope. The singular version lacks that guard.
The HTTP bridge's own extract_channel_from_filter
(crates/buzz-relay/src/api/bridge.rs) also gets it right (None unless
exactly one value) — but it feeds only the access-scope check, not the query
builder, so the narrowing still happens underneath it.

User-visible impact

Buzz Desktop's global Workflows screen sends exactly this shape — one batched
kind:30620 query with every member channel in #h
(desktop/src/features/workflows/ui/WorkflowsView.tsx →
get_channels_workflows). For any user whose alphabetically-first channel is
a DM (typical), the screen renders "No workflows yet" even when workflows
exist and run. Refresh does not help. Any other client using multi-#h
filters is affected the same way.

Reproduction (empirical, self-hosted relay at 788b3c0)

NIP-98-signed POST /query, requester is a member of all channels named:

#h values	Result
[apiary]	2 workflow events
[dm-sorting-before-apiary, apiary]	0 events
[dm-sorting-after-apiary, apiary]	2 events

Every combination follows the sort rule. Repro script available.

Expected

Multi-#h should scope to the UNION of the listed channels — e.g. push the
whole set down as a channel_ids IN-list (the mechanism the access-scope
path already uses) instead of first-value narrowing, or fall back to
global scope + post-filter as extract_channel_id_from_filters does.

Notes

filter_fully_pushable already declares multi-#h "not pushable", so the
fast-COUNT path correctly avoids it — the defect is only in the query-scope
builder. A fix should add a regression test: multi-#h filter returns events
from ALL listed channels regardless of sort order.

A PR with a proposed fix (IN-list pushdown + regression tests) follows
shortly and will be linked here.

[BrettHamlin]

Confirming this independently against 8342dfcc, and adding one detail on the HTTP bridge path that I don't think is covered here or in the open PRs.

Reproduction

Throwaway relay on random ports, one community, one open channel and one private channel, an active bot member, kind-9 events published from a different identity. Five queries against the same instance:

Experiment	open	private
HTTP multi-#h, member reader	1	0
HTTP single-#h, member reader	—	1
WS REQ backfill, member reader	—	1
WS REQ live push, member reader	—	1
HTTP multi-#h, channel owner reader	1	0

The last row is the control: an owner of the private channel also gets nothing back from the multi-#h HTTP query, so this isn't an authorization decision — it's the query path.

The bridge path has a second, separate cause

Most of the discussion (and PRs #4393, #4624, #4693) focuses on the singular extractor. On the HTTP /query catchall there's an additional interaction between two different extractors with the same job and different semantics:

• handlers/req.rs:858 extract_channel_id_from_filter is lenient — returns the first parseable UUID from #h regardless of how many values are present.
• api/bridge.rs:235 extract_channel_from_filter is strict — Some only when #h has exactly one value.

At api/bridge.rs:1227-1238, both are used on the same filter:

let mut query = crate::handlers::req::build_event_query_from_filter(  // uses the LENIENT one
    filter, &pubkey_bytes, state, tenant.community(),
).await;
crate::handlers::req::apply_access_scope_to_query(
    &mut query,
    extract_channel_from_filter(filter),                              // passes the STRICT one
    &accessible_channels,
);

So for #h: [A, B], build_event_query_from_filter sets query.channel_id = Some(A) (first value), while apply_access_scope_to_query receives None and takes its channel_id.is_none() branch, setting query.channel_ids = Some(accessible). Both predicates then AND together — the query is pinned to channel A and intersected with the accessible set. B is never queried.

That's consistent with the observed table: whichever channel sorts first is the one you get, and everything else is dropped regardless of membership.

Why this matters for the fixes in flight: making the singular extractor return None for multi-value #h leaves channel_id unset, so the query falls through to channel_ids = accessible — which returns events from all accessible channels rather than the ones the filter actually asked for. That trades a narrow under-fetch for a filter-correctness bug. Of the open PRs, only #4581 touches apply_access_scope_to_query at all.

Suggested shape

The codebase already has the right pattern in the NIP-50 search path at handlers/req.rs:568-584 — intersect the filter's #h values with the caller's accessible set, and skip the filter entirely when the intersection is empty, with the comment "rather than broadening". Applying that same shape here would resolve both the omission and the multi-channel case, and keeps the scoping expressed as an intersection with what the caller is entitled to rather than as whatever the filter requested.

Happy to put a PR together if that's useful, but given there are already four open on this file I'd rather defer to whichever one maintainers prefer.