Spam filtering has been a basic relay activity since day 1. I don't think adding spam filtering moves us to smart relays, dumb clients.
Also, the reason I don't see much spam is because Amethyst also has spam filtering. So, it's not that clients are giving up.
In the end, clients alone can't solve this. Relays alone also can't solve it. Both need to be developed to make things work.
What kind of spam filtering do you do? Basic wot or something more traditional?
Super basic stuff like looking for duplicated content, selecting user lists for notifications (wot), sentence hiding using post + profile info (so spam keys must not have a user metadata, otherwise it's easy to filter).
But I want to do a more traditional 5-levels deep wot DVM to add to the process.
nice, those are good
Seems like the latest spammers are using random content from random posts, with random duplicate profiles, so the duplicate content thing is easy to get around, especially if they fudge it a bit :(
Yeah, if DVMs are not available, I think it would be best to start marking users as "interacted with before" and then filtering by those. Meaning, you have to have liked or replied to the person before to show up on notifications.
Which is very similar to how we separate known from new people on DMs.
Meaning WoT from the reply/like/zap information, not only from the follow list.
Exactly what ive been thinking, except in my design these are inputs to a pluggable nostrscript anti spam algo
Nice! I might start creating a User Status event for every new interaction, putting them into the "interacted with" list
This is what I’ve been on about for months … WoT filtering (of bots and bad actors) is too much work for clients to handle and unnecessary burden for relays to deliver all the spam. The bulk of WoT filtering NEEDS to be handled “server” side.
The “only” problem with “smart relays” is possible lack of choice and transparency for end users.
Now we have WoT relays … Soon we will have “smarter” WoT algos (as nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s and nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z mention bellow) using more than just follows follows. These algos will be accessible to end users (in any client) via relay feeds, custom nip51 list feeds, and via DVMs. In addition, clients and relays themselves will be able to access algo APIs directly, to offer their own white labeled solutions.
I am currently working with nostr:npub1u5njm6g5h5cpw4wy8xugu62e5s7f6fnysv0sj0z3a8rengt2zqhsxrldq3 and nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h on My Grapevine (https://grapevine.my), to spearhead open source development of WoT algos and user centered WoT services.
In the end, we envision an open and accessible market FULL of WoT solutions that end users can choose from (and recommend and share with each other).
But yea, nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac , WoT filters on the relay is still well within the scope of “pure” old skool nostr.
IMHO
