I see. Its ok, I don't know for sure, probably i suspect one of my follows have followed the spam account. Their follows make the spam account included in filter relay.
Lol, unfortunatey, this "Spam Cat" generate multiple account which hard to block individually
I’ll take a look at chats in particular a bit later today. We hadn’t dug deeply in to those as they aren’t in our client.
I doubt my situation is from a follower unless I'm following someone auto-following all the spam accounts. I actually believe it's more likely because Amethyst lumps NIP-28 messages into global feed. Does filter pull all NIP-28 events?
I was block/reporting the same Cat spam from multiple different pubkeys but it would instantly appear again. I checked which relay it was coming from and noticed it was the filter relay which didn't make sense until I realized that Amethyst global was pulling in NIP-28 messages and I assume that filter is considering that NIP-28 group message as a shared event so it's pulling those NIP-28 messages I'm a part of in for me. Amethyst then sees new NIP-28 and feeds to my global.
Ok thank you for this. I believe this isn’t a follow now with more context.
It’s a bit long to explain but the gist is depending on how the client sends us the global channel requests we may NOT be currently filtering the response.
Not sure if we should be filtering all channels or not (could hurt with following the conversation) but we will take a look today.
Great mazin, if you got the gist of it. As me, Patrick, and other users are probably not sure. You can improve the filter bit by bit.
I don't think there's much you can do beyond spam filtering the filter relay because the only alternative would be to stop bridging NIP-28 which is probably one of the intended goals of the filter in the first place. I think the best solution would be for Amethyst to keep NIP-28 out of global IMHO or at user level just leave the defaulted Nostr and Amethyst group chats so spammers don't have those huge honeypot rooms to broadcast to.
Filtering our aggregator is definitely on our to-do list. Strfry has an amazing update in pipeline that will let us run our own models on event data we are streaming from big relays as it comes in. There are some patchy ways to deal with it now but we wanted to start with a big net and refine.
Soon…
Thank you so much for this info btw, very useful.
Basically you’re exactly right but we can consider adjusting our current methods to support channel message filtering in this context (if it’s desired).
