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. nostr:note18z7rqv87qt0nu3v0rajf4ghnrqcnnc3ujgeqy3zswgs2nwh3nq3qmwhnlh

Reply to this note

Please Login to reply.

Discussion

forgot about these regex filters! still a WIP or in PR yet? can’t wait to try them out awesome work.

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.

This was part two of the mock.

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.

Keyword and keyword list filtering would be amazing!

Yep, it's a tricky balance to give a granular choice to users without making the UI clunky and cluttered. I want more refined control, but many don't and won't care.

This is one of the most meaningful response I have seen regarding this issue. Thank you so much.