good catch!
Discussion
this is the second time i've poked #[3] about it but he seems to be ignoring it. i may be forced to implement a blacklist in my indexer. but that might quickly turn into a game of whack-a-mole.
idk too much - but anything open means also open other agencies who can make bots n have powerful resources - u see how tor network get attacked time to time - these things will evolve - like tcpip - very early days much before VPN - institutions were not jumping packet network - sticking to OWN dedicated Frame-Relay X.25 n other such networks. nostr has long way to go
i'm a techie and i'm being far more patient about Nostr flaws and complications than the average user would be. but i they're still flaws. they need to get fixed ASAP. one of the things Steve Jobs was good at was to be a nazi about UX. was it pleasant to his employees? most decidedly not. did it create a smooth experience? most definitely yes.
having worked for 15 years in dev, my general impression is that if a dev hates doing it, the user will love it.
it's the "this is why we pay you" part of the job - the bit where you have to do a lot of stuff that sucks to make it suck less for the users.
yeah that thing any tech -> if u want it to be #adopted by general #crowd #SIMPLIFY n SERVE
80% are not like us pro-tech early adopter - they will happily pay whatever they can afford - Apple was always expensive n always will be - their appeal is SIMPLIFICATION ! there will always DIY Linux worshipers n good ol windows
when designing a user interface, assume that the user has zero patience and will ruthlessly abandon your software if it isn't smooth.
you may hate this, but it will help it get wider adoption.
to the user, programmers don't exist. what they click or poke with their finger does. your preference of framework is irrelevant.
prefer what causes that click or tap to go faster.
prefer what doesn't cause the laptop to spin the fan up. if you make code that causes fans to spin up, this will cause people to buy a new computer. this isn't necessary. you can just write efficient code instead.
💜
Hey sorry not ignoring just by nature of how filter works right now there isn’t much we can do about this. Filter shouldn’t be indexed anyway as it is an aggregator so if you read from our public relay list you will pull only duplicates from filter.
The only “filtering” we do on filter.nostr.wine right now is on specific “global” requests including kind 1 events.
We will eventually introduce spam filtering on ingress but we wanted to start with the largest possible net.
Using filter.nostr.wine as intended works as documented in https://filter.nostr.wine
we have talked before and i actually read documentation. i know what i'm doing. and the things i make are ultimately intended to make Nostr a better experience.
i've been posting about spam filtering myself and i think you get a pretty clean feed if you stuck a naive Bayesian classifier on a relay pool. i've been thinking if i should make an aggregator similar to filter.nostr.wine except it uses that algoriithm.
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...
a lot of the relays that filter.nostr.wine reads from are a bit hard to actually get responses from directly. many of them don't seem to respond to queries. i'm not sure why.