I've added certain instances (e.g., pawoo.net) to my Mitra's blocked instance list within the .yaml config---however, I'm still receiving content from those instances?

christmas skibidi tomato :nix: :tomatock:

@adiz @silverpill hmm that's weird because I've blocked instances and it does work for me. lemme check

christmas skibidi tomato :nix: :tomatock:

looks like this for me. btw i always restarted mitra when changing config.yaml @silverpill @adiz

👺防空識別區👹 （mix mastering）

@mischievoustomato I always restart Mitra as well. Maybe I need to move the ending bracket down a line and the top entry under the opening bracket? I didn't know it would accept comments inside the list, either. That's great for organizational purposes. I'll try doing that and restarting the service. @silverpill

christmas skibidi tomato :nix: :tomatock:

@adiz @silverpill i didnt know either lol i just did it

👺防空識別區👹 （mix mastering）

@mischievoustomato I changed my config closer to what you've got both in syntax and organization. Restarted Mitra and it's running fine. We shall see, I guess? @silverpill

silverpill

@adiz @mischievoustomato blocked_instances only blocks messages pushed to you, but it doesn't block messages that your server pulls (for example, when processing a reply), so you might still see them. It also doesn't delete existing posts, it works like a firewall.

The ability to block outgoing requests will be added later. Let me know if this is important.

I also recommend using mitractl add-filter-rule instead of a config file. I haven't documented how this new filtering system works, but you can read about it here: https://www.knthost.com/mitra/create-and-manage-mitra-filters

👺防空識別區👹 （mix mastering）

@silverpill
> The ability to block outgoing requests will be added later. Let me know if this is important.

Blocking outgoing requests is important to me since most of those instances I have "blocked" were meant to block outgoing requests, primarily, vs. incoming. Because most of those instances are known bad-actor #fediblock bandwagon instances who get off on dog-piling and sabotaging other instances for the most minor of transgressions or ideological heresy. I've found it best practice to simply block those instances outright from the outset so that no federation takes place and one remains entirely off their "radar"---everyone's happy. One doesn't receive activities from them (they've nothing I want to see or hear) and the don't receive any activities from you (they've noting to complain about or disparage and attack you over). Otherwise, they'll go out of their way to look for problems and will then publicly crucify your instance and you'll end up on a list from which hundreds of instances will blindly follow. @mischievoustomato

👺防空識別區👹 （mix mastering）

@adiz @silverpill Also, really good documentation about mitractl add-filter-rule! I didn't see these docs on the repo. Looks like it functions very similar to ufw, which is quite intuitive and straightforward. Might I ask why you recommend using mitractl vs. directly modifying the config? Does it do the same thing ultimately? @mischievoustomato

silverpill

@adiz add-filter-rule is a different system. It stores rules in the database and is more powerful. It can remove media attachments without blocking instance entirely, and eventually will be able to do other things like removing profile images and hiding posts from the federated timeline (similar to Pleroma's MRF). Since rules are stored in database, they can be edited from a web client too (though that hasn't been implemented yet). And you can combine mitractl with other command line utils to load rules from a CSV file.

The new system is intended to be a replacement for configuration parameters.

@mischievoustomato

👺防空識別區👹 （mix mastering）

@silverpill Ah, very cool! I had no idea. Yeah, it sounds a lot more powerful. I will definitely have to get mitractl configured and setup to begin doing that and utilizing it. Being able to backup or load rules from a CSV also sounds huge! This is powerful, really straightforward and reliable kind of implementation vs. what a lot of other instance softwares do. Thanks for taking the time to better explain this stuff! I'm really excited to see the future of Mitra's evolution. @mischievoustomato

👺防空識別區👹 （mix mastering）

@silverpill As far as blocking out instances entirely from federation whatsoever, I think I will probably follow @mischievoustomato 's advice and configure /etc/hosts to do that. Honestly, it's kind of like that functionality doesn't even need to be in Mitra if it's already included within Linux itself.

silverpill

@adiz @mischievoustomato Doing blocking directly from Mitra would be more efficient, but yes /etc/hosts is good as a temporary solution.