"Safe space" install in CLI

[aumetra]

Basic idea:

• Enable authorized fetches (after implementing #251 and #267)
• Download list from The Bad Space (we will choose a different default list) and load them into the federation filter (some basic CSV parsing and editing via toml_edit)

These two things should make for a pretty good safe space, making blocks effective and blocking a large amount (958, as of the time of writing) of known bad actors.

It's by no means perfect, but should make for a good and safe default.

[aumetra]

Actually, a mechanism to allow fetching new blocks from known trusted sources would be nice. A compatibility layer between the Mastodon CSV format and our format would be needed, but nothing too difficult.

Something like:

kitsune-cli block-sync -f blocklist-sources.txt

where the blocklist-sources.txt is a newline delimited list of URLs.
This + some guidance in the documentation could replace us choosing any default list and let the admins choose for themselves.

[tesaguri]

This + some guidance in the documentation could replace us choosing any default list and let the admins choose for themselves.

I love that change as I'm not a big fan of the idea of Fediverse server implementations bundling a default block list, which might give too much power to whomever controls the list (like Spamhaus in the world of email, which can virtually kick any small server out of the world as it pleases just as if it were a centralized platform) and might impose moderation standards of a single culture (well, of the West in particular) to everyone around the world (e.g. The Bad Space blocks mstdn.jp, the second largest Mastodon server for Japanese-speaking users. That decision may make sense if you (or your users) are unfamiliar with Japanese, but the decision would be far more controversial for Japanese-speaking users. I think it's like blocking qq.com in the world of email).

That being said, another feature I'd like to see is an ability to sync removal of blocks from the list, since the list editors might add a domain by mistake and later correct it, or the blocked server might improve its moderation and get delisted. Though I expect that its implementation would be tricky (if possible) with TOML format. Here are some ideas on the design:

• Move the federation filters to the database: we would be able to mark blocked domains as "imported from a list" so that they can safely be deleted when syncing the list.
• Mark domains as "imported" in TOML: something like imported_domains."thebad.space" = ["example.com"]
• Go back to Dhall format (well, just saying): you would be able to make a Dhall file corresponding to the list and import it from the main config file. The sync could then simply be done by clearing the imported file and replaces it with the new list.

I like the first option because it would also allow multiple moderators (including those of virtual instances (#179)) to manage the lists, but it would require a lot of implementation work.

[aumetra]

I would be more for an untagged enum approach here for the time being:

[instance.federation-filter]
type = "deny"
domains = [
    "bad.actor.example",
    { domain = "somewhat-neutral.example", reason = "Excessive spam" },
    { domain = "other-instance.example", reason = "Imported from blocklists" }
]

But the first (database-based) approach would be very much viable, too.

[aumetra]

might impose moderation standards of a single culture (well, of the West in particular)

I agree with this. There are different moderation standards per culture someone might want to enforce.
The documentation could possibly point to different blocklist for different types of communities.