The filtering/blocking approach used by Amethyst today has a few main faults - the primary one being lack of visibility of app wide filtering. People find out by accident, or at all - which is obviously a sign of a broken approach. I don’t quite see it as censorship, yet more as a poorly functioning content ‘value’ scoring system. The inability to opt-in and customise your filters is really the lacking feature here. I’m actually surprised just how badly the WoT - trusting 5 nth degree following spam reports = shadow ban content - has performed. It shows that close/greater connected individuals (group clusters) regularly have different preferences and desires to self-curate what they see - instead of having it done on their behalf somehow (I.e. WoT signals). People also report or mute for many reasons - from bad content to “I just don’t care about this type of content”. Breaking News: Humans value different things. Enabling users to self curate more easily and see how far that gets us is the best approach. We can even add filtering for NIP05 domains, or perhaps relays to avoid connecting to. Even content warning, profanity masking, nudity detection, etc. all done locally on devices without major performance impacts. Damus POC I mocked up. Damus has active development in this area. image
iefan 🕊️'s avatar iefan 🕊️
IMPORTANT: If you are here because you see Nostr as a censorship-resistant alternative and the beacon of free speech, YOU MUST READ THIS. Something bad is going on, and you should be aware of it. It affects every user on Nostr. First: Please, only utilize the 'Report' feature in extreme cases. Instead, prioritize using the 'Mute/Block' option when necessary. This is a humble request to all the IOS & Android users 🙏 Because we have a very huge problem and it's not a bug. Let me elaborate: Regardless of where you choose to report, your 'report' will censor that person not just for you but "all of your followers" who use Amethyst. It only takes five reports from 'following user' to censor the individual "for you" without your intent and knowledge. No matter which client the censored user is using, they will be censored for Amethyst users after reports. Amethyst users don't even have an option to turn off this setting. This is really messed up. Any five users I am following can censor any person for me, and I can't do anything about it. This is ridiculous. By the way, don't make any mistake here, it's not a bug, it's by design. I raised this issue with Vitor many times. I respect his work, but there has been no meaningful response regarding this. In fact, he wants you to learn coding and do it by yourself. I don't intend to call out any person; I just want to spread awareness. Maybe you like this feature idk but you deserve to know what's exactly happening and make informed decisions. Btw, You don't have to share this exact post, but please let people around you know what's happening. So they can participate in this debate.
View quoted note →

Replies (9)

I can’t say for sure, however I imagine twitter purposely made reporting accounts a 5-8 click painful process. I suspect that’s due to the noise it produced - even in a centralised and KYC environment. They didn’t know how to make the report data useful. It obviously wasn’t part of their strategy to manage bots - as it almost seemed like an afterthought.
HoloKat's avatar
HoloKat 2 years ago
Keyword and keyword list filtering would be amazing!
I forget who, but I was told someone had started to work on client filtering for Damus. I shared my concept and haven’t followed up since - if we don’t see much action, I may circle back and progress the mock up toward a functional PR. It’s mostly just Swift UI and data models so far - it’s missing the query hook to filter data. I suspect it may need a couple performance smarts, as pre-rendering is a performance sensitive area. Things like filtering based on NIP05 requires kind0 for that pubkey - so you ideally don’t want to show it, fetch kind0, match on filtered NIP-05 and then hide it.
nice, the layout LGTM. I assumed the naive approach of filtering events after they’ve been received. actually, I wonder if that is viable after all - string matching is cheap
It worked fine for Tweetbot. Definitely my preference is filtering client side - as the the relay query results are processed. JB55 has put a lot of effort into making events fetch and render fast. Adding filtering, will have some additional computation. Obviously more filters will mean more non-linear computation. Just need to build it and test really - no point optimising without seeing how a minimal approach goes. At some point I envision a smarter relay query NIP drafted and can support filters or rules. It’s perhaps a bit early, while what we have largely works ok.