More subs and less filters / sub

[vitorpamplona]

This is in support of and to prepare for nostr-protocol/nips#1645

[hoytech]

Sorry, I haven't been tracking all the NIP progress. Is this still the way forward? Looks like @fiatjaf closed the NIP above.

[fiatjaf]

After too much drama I decided to end my quest to support a single filter per REQ.

I still think the way forward is to limit REQs by filter, not by REQ. Or, better, by query cost (i.e. a query with two pubkeys costs twice more than a query with a single). That would probably move us closer to a fairer and better world regardless of protocol changes.

[hoytech]

Makes sense. This probably will impact some clients, but I don't really know what the blast radius would be.

I'll hold off on merging this for now, but let me know if I should before the next release.

[fiatjaf]

I think merging this PR is probably a good thing, but not super important either way.

[vitorpamplona]

This is important to make the client's life easier. Nobody changes default settings, and because StrFry is so well used, this becomes the way nostr works. And because the current defaults only allow 20 subs, clients have to make additional logic to merge multiple subs into one REQ, which turns pagination/EOSE management into a mess.

Please consider it.

[hoytech]

Merged. Thanks!

[vitorpamplona]

Quick add-on here. From my side, we don't need to reduce the Maximum number of filters allowed in a REQ to 20 if you are concerned about breaking some clients. We can keep both values at 200. That shouldn't break anything.

[hoytech]

OK sounds good, I put it back to 200 to minimise disruption: 1a8e7ff