In general I agree with both of you. Filtering can be done either side. Personally I prefer client-side filtering and dumb relays because it puts me in control. I don't get to choose the relay that...
> Asking relays to compute WoT so you don't have to upload long lists of pubkeys has performance consequences and I'm not sure if it is better or worse.
The relay could
* cache lists
* work with lists from events for direct follows
* explicitly take a follows-degree argument to do the heavy lifting for the client
I find most important that these views on nostr are pubkey dependent and not relay dependent.
If I provide a giant filter using my 3rd degree follows, the relay could instead of building giant DB queries with it, filter results by that list or compress the list into a probabilistic filter using a tiny fraction of the original space to apply that logic of post filtering.
The requester should be charged for any such kind of heavy lifting.
The relay could
* cache lists
* work with lists from events for direct follows
* explicitly take a follows-degree argument to do the heavy lifting for the client
I find most important that these views on nostr are pubkey dependent and not relay dependent.
If I provide a giant filter using my 3rd degree follows, the relay could instead of building giant DB queries with it, filter results by that list or compress the list into a probabilistic filter using a tiny fraction of the original space to apply that logic of post filtering.
The requester should be charged for any such kind of heavy lifting.
1