Yes, that is very likely true today. We are waiting on a small feature from our relay implementation and then we will begin our own modeling. Dealing with the curren spam on nostr will be child’s play for #[4].
We suspect the challenge will increase in the future!
before i decided to let email be someone else's problem, i was using bogofilter on my email. i had been using SpamAssassin before. it had other filters than the Bayesian classifier, but as i discovered, using those other filters made it worse. the classifier was the best part of it. bogofilter was the first Bayesian email spam filter. so i dropped SpamAssassin and just filtered with Bogofilter and a lot of bloat was eliminated. #[5]
(when i say Bogofilter was the first, i don't mean my first. it was literally the first to use that method of spam filtering. it's still being actively maintained.)
Yeah! Naive Bayes has a great history in email spam detection (and honestly I love it for a lot of short text string classification in general). I think the approach will be an ensemble approach, one leg of which will definitely be utilizing bayes.
if you're going to have a classifier in there, you might consider to just have the other filters be an input to the classifier. after all, it can be trained to consider certain inputs important.
as you suggest the classifier could be trained as it goes. What if the filter is also client side, the user can train its own classifier to detect what it doesn’t like
some clients try hard to be intelligent, such as iris.to. but it spins the fan on my laptop too much. maybe a balance should be struck.
one of the reasons that Nostr appeals to me is how the protocol itself is fairly lightweight. some of the clients i come across could stand to be a little lighter too...
