Whether a notification with this JSON-RPC method (and, for notifications/resources/updated, this resource uri) is one this stream explicitly requested. An inactive filter (a plain GET stream) accepts every notification; an active filter accepts only its opted-in types. Notification methods that are not subscription-gated (progress, logging, elicitation completion, server->client requests, etc.) are always accepted — the draft filter governs only the four list/subscription change types.
true once this is a real subscriptions/listen filter
opted into notifications/resources/updated
the exact URIs opted into for notifications/resources/updated
The per-stream opt-in a client expressed when it opened a draft subscriptions/listen stream (draft basic/utilities/subscriptions §Notification Filter). It records exactly which change-notification types this one stream asked for, so the server can honour the MUST NOT: "The server MUST NOT send notification types the client has not explicitly requested." With Multiple Concurrent Subscriptions each listen stream carries its own filter (keyed by its listen request id), so a notification is delivered only to streams that opted into it — never to a concurrent stream that requested a different type.
active distinguishes a real listen-stream filter (an opted-in draft stream) from the zero value used for plain GET streams that did not go through `subscriptions/ listen`; an inactive filter accepts everything, so the plain GET stream still obeys only the transport's Multiple Connections rule.