mirror of
https://relay.ngit.dev/npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/ngit-grasp.git
synced 2026-10-05 15:08:24 +00:00
DanConwayDev
b21683b0f9
Archive burn-in against relay.jbnco.co exposed repeated CLOSED responses for eight-filter REQs. This is unusually strict among the surveyed relay implementations, although it matches strfry's optional strict filterValidation default. Empirical NIP-01 probes of relay.jbnco.co found: - 1-3 filters were accepted with EOSE. - 4-12 filters were rejected. - The error number was the submitted filter count, not the maximum. Recognize only strong filter-count refusal phrases, geometrically lower a per-connection-session grouping ceiling from the actual rejected group size, and re-derive the exact rejected historic batch or complete live coverage. Both live and REQ+EOSE grouping consume the learned ceiling. A one-filter refusal falls through to the existing 24-hour filter-incompatible policy pause. The learned value only decreases and resets on reconnect. This avoids trusting non-standard free-text numbers: strfry echoes the submitted count while rust-nostr names its configured maximum. Ordinary defaults remain at ten to avoid consuming unnecessary subscription slots on relays that accept common group sizes. NIP-11 extension work, upward probing, persistence across sessions, and adaptation for ambiguous generic validation failures are excluded. Generic unsupported-filter responses retain policy backoff rather than being misclassified as count evidence. Validation: live tests against a rust-nostr relay capped at three filters prove a four-filter refusal learns two and preserves subsequent q-tagged event delivery. nix develop -c cargo test --lib passed all 670 tests; the focused integration and classifier tests also passed.