Onion Information

Page Clicks: 0

First Seen: 03/11/2024

Last Indexed: 10/21/2024

Domain Index Total: 190

I moderate the “pleroma.envs.net” Akkoma instance on the Fediverse, as @Seirdy@pleroma.envs.net . I maintain four main blocklists for the Fediverse. Do not import them until you’ve read everything until the “receipts” section. I encourage blocklist skeptics to read the “receipts” sections, and to treat them as lists of reported content rather than importable blocklists. The pleroma.envs.net blocklist A large list of instances that I find worth suspending. After the first couple hundred entries (imported and then reviewed), I started collecting receipts. Since early 2023, every entry has documented reasons and receipts. I share these with multiple people in a collaborative document, but I don’t share it publicly due to risk of harassment. Unlike the other two lists on this page, it wasn’t made for general use. You’re welcome to use it as reference, or as one of many sources for a consensus-based list with a minimum required consensus level. tier0.csv A much smaller semi-curated subset of pleroma.envs.net suitable for the majority of instances wishing to uphold the Mastodon Covenant’s moderation standards, though somewhat heavy-handed. I hope to make it a good starting point for your instance’s blocklist, with wiggle room for your own adjustments. I encourage you to add and remove entries as you see fit. Regularly importing tier0.csv won’t account for retractions; a sibling blocklist for tier-0 retractions exists for FediBlockHole users. Note that this list is larger than the bare-minimum I recommend. the bare-minimum is FediNuke. If you’re skeptical of imported blocklists, you should start there. If you run an instance for many others: please do not blindly import this list unless you intend to review its entries. FediNuke.txt A curated subset of tier0.csv , containing what I deem the “worse half” of it. This contains instances I really do recommend most people block, or at least avoid. I try to make it a suitable candidate for a “default blocklist”, and use it as reference when I evaluate the quality of other blocklists. This list is not comprehensive; to keep this list small, I excluded many really bad instances. I take into account not just severity, but also notoriety and likelihood of reaching/harming people on other instances (e.g. spewing toxicity in others’ mentions, running block-notification bots, etc). Bad instances that mostly keep to themselves are less likely to cause problems for a new admin, and therefore less likely to get included in this minimal list. Finally, I take into account controversy; in order for this blocklist to fulfill its purpose of widely defederating the worst actors, no entry on it should be too controversial outside of the parts of Fedi already likely to reach tier-0. Criteria are not set in stone. Instances well-known for causing significant problems for many other instances, particularly for instances run by and for marginalized groups, may be added. All these lists, just like all my content on seirdy.one, are CC-BY-SA licensed. However, I’d rather you not use them in another blocklist-related project without contacting me first. I made a lot of decisions about how these blocklists work and learned some tough lessons; I’d rather not see someone repeat my mistakes. This post is an attempt to document how they are made, their differences, their intended use, and especially their caveats. It also contains a work-in-progress list of receipts for instances in FediNuke and my Tier-0. Toggle table of contents How Tier-0 and FediNuke work My tier-0 list is a subset of the pleroma.envs.net blocklist. It contains entries that appeared on at least 15 out of 27 other hand-picked instance blocklists (“bias sources”), with exceptions detailed below. Not all Tier-0 entries have the same level of severity; a smaller list containing what I personally deem the “worse half” of Tier 0 is FediNuke.txt . Consensus builds Tier-0; severity builds FediNuke. When I add a bias source, I may also increase the minimum number of votes required if I find that its blocklist is too close to (or mainly just imports all of) tier-0 or the blocklist of a bias source’s blocklist. That’s the reason why the threshold is 15 instead of 13 or 14. All entries use the root domains when applicable, or are as close to the root domain as possible without triggering false-positives. Overrides There were some block-overrides for instances with fewer than 15 votes. Here’s how I went about overriding: If an instance has 10 votes, I may elect to add it after additional review instead of waiting for it to hit 15 votes. If an instance is run by the same staff as another Tier-0 instance and has at least 5 votes, I may add it after asking other admins about it and getting multiple thumbs-up from admins who import tier-0. If an instance contains blatant/unapologetic bigotry (something really undeniable, like Nazi imagery or excessive use of slurs in violent/hateful/definitely-not-reclaimed contexts) with staff approval or involvement, I may add it to both tier-0 and FediNuke.txt after I get multiple thumbs-up. If an instance becomes risky even to many tier-0 instances (untagged gore, dox attempts, significant cybersecurity risk, CSAM , etc. with staff approval or involvement): I may add it to both right away, skipping any process. This is rare. Under ten controversial entries were excluded despite having more than enough votes, after consulting with other admins. Typically, these were instances that didn’t pose a major safety risk, but did fail many admins’ “vibe check” or exhibit major governance issues. I also excluded Twitter mirrors such as BirdSiteLive and bird.makeup, and bridges to other social media platforms; I maintain supplementary lists for those that don’t require consensus. Bias sources Criteria for a bias source: Has a blocklist I can easily download, possibly with an API key. Practices timely and proactive moderation: doesn’t just wait for another instance start interacting and cause trouble, and updates more often than once a month. Evaluating this takes time. Blocks at least half of FediNuke.txt . The final tier0.csv isn’t a pure representation of agreement between instances; it contains overrides and is merely a subset of the pleroma.envs.net blocklist. Other lists only serve to determine the bias used for filtering the pleroma.envs.net blocklist. The pleroma.envs.net blocklist is technically the only “real source”. Other bias sources shouldn’t be held responsible for the final tier0.csv contents. I’ll explain my motivation for doing this in the next section. Since accountability for tier0.csv rests on me rather than on other instances, I don’t publish the current bias sources. Blame for any problems in tier0.csv should rest with me, not them. Motivation for including personal bias If tier0.csv were merely an unbiased list of the most widely blocked instances, then being on the list would become a self-fulfilling point of no return. If an instance gets blocked by enough other instances, then it shows up on my lists. If an instance shows up on my lists, it will get blocked by other instances which import my lists. If more instances block it…you get the picture. This leaves little room for retractions and mistakes. By making all my blocklists a subset of the pleroma.envs.net blocklist, I ensure only one party needs to be convinced to remove an entry. Some instances migrate their domains. If the old instance was already deemed worthy of a suspension and the new instance maintains the same staff with no visible attempt to change its reputation, then I deem the new location to be as block-worthy as the old location and make an override. It’s the same bad actors under a different banner. Refreshing Refreshes are a manual process. Refreshes update my tier-0 list, but do not update FediNuke; that list is a manually-curated subset of my tier-0 list. Every time I refresh, I get prompted with changes (if they exist) so I can review them. Since my tier-0 is a subset of the pleroma.envs.net blocklist, all additions should have some level of approval from me already, but I’ve started giving new additions a second look anyway. Manual review, subsetting the pleroma.envs.net blocklist, having a large number of bias sources, and some level of vetting for my bias sources should mitigate the risk of one bias source “going rogue” and compromising its blocklist right before a refresh. Retractions A separate list exists for retractions from my tier0.csv list. I don’t add entries to my retractions list when I remove dead instances, or when an admin on a removed instance prefers not to be included in it (some wish to remain less prominent). Intended use The original goal was to make a blocklist appealing to instances with a more laid-back moderation approach, so that they would actually implement a decent blocklist and limit the reach of the worst actors. Unfortunately, the final tier0.csv blocklist is 350+ entries; this is still a bit much for the moderate instances. I pared that down to FediNuke.txt , which contains instances that were both really bad and well-known. It’s kind of hard to overlook how shitty each instance on the FediNuke.txt subset is. Common themes tend to be repeated unwelcome sui-bait note 1 from instance staff against individuals, creating or spreading dox materials against other users, note 2 unapologetic bigotry, uncensored shock content, and a complete lack of moderation. I think if you’re starting a well-moderated instance, Tier 0 is a decent place to start (that’s why it’s in the standard CSV format). You should add and remove entries as you see fit. If you’re making a client and want to give it a built-in blocklist, or are looking for a good “default” blocklist: FediNuke is a good option. However: if your instance grows larger (or if you intend to grow): you should be intentional about your moderation decisions, present and past. Your members ostensibly trust you, but not me. See the “trust but verify” section for more information. Rationale for creating two subsets I used to just make a Tier-0 list. Later, I added the FediNuke list. Some people have asked why I don’t just use one or the other; if Tier-0 was big enough to warrant FediNuke, why publish Tier-0 at all? I have two reasons for maintaining two blocklists: I didn’t feel comfortable placing some Tier-0 instances right next to, e.g., openly Nazi instances when they weren’t at the same level of severity. FediNuke’s existence establishes that some instances on the list are much worse than others. Maintaining multiple blocklists makes their subjectivity more obvious. The lists can work together. As I previously mentioned, the division makes it easier for people to feel comfortable importing blocks. Some admins have found that importing FediNuke and gradually combing through the rest of Tier-0 is more approa...