A Bluesky moderation list can be useful. It can also be too broad for your account.

I do not subscribe to one blindly. I fork it, remove the accounts that do not match my threshold, then decide whether to mute or block the fork.

Use TheBlue.social's Bluesky moderation list forker when you want that review step: paste a public moderation list, remove accounts, create your own version, then mute or block from Bluesky.

Start with what a moderation list does

Bluesky lists have a purpose.

The official user lists documentation defines app.bsky.graph.defs#modlist as a list of users for muting or blocking. The same page says curatelist is for feeds or thread gates.

Choose the list type before you take action.

A curated list says "I want to group these accounts." A moderation list says "I may apply a safety or noise-control action to these accounts as a group."

The docs describe list mutes and list blocks separately:

  • muting a list uses app.bsky.graph.muteActorList, and the mute state is private
  • blocking a list creates an app.bsky.graph.listblock record, and blocks are public records

So I treat a moderation list like an account-level decision, not a reading list.

Why I fork instead of subscribing immediately

Shared moderation lists are useful because someone else has already done the first pass.

They are also opinionated.

The creator may have a different threshold, a different topic, a different local context, or a different risk model. A list made for one community can be too aggressive for another. A list made during a messy event can keep including accounts after the event is over.

Forking gives me a copy I control.

I keep the source context, but I do not inherit every decision. If I remove 40 accounts from a 300-account list, that is not a public argument with the creator. It is just my moderation threshold.

I like the forking workflow because it keeps those two things separate: credit for the original work, and responsibility for my own account.

What I check before creating the fork

I do a fast review first.

For each source list, I check:

  • list name and description
  • creator handle
  • member count
  • whether it is actually a moderation list
  • whether the reason for the list still applies
  • whether the list targets behavior, topic, spam pattern, or identity

The last item matters most.

I am comfortable using lists that target a clear behavior or spam pattern. I am much more careful with lists that mix disagreement, old conflict, vague labels, or accounts included by association.

TheBlue.social flags non-moderation lists when you paste them into the forker. You can still inspect a normal list, but Bluesky mute and block subscriptions require a moderation list.

Read the reason before the members

I look for a reason before I look at individual accounts.

A useful moderation list usually has a narrow reason:

  • obvious spam accounts
  • impersonation attempts
  • scraper or bot networks
  • accounts targeting one community
  • accounts tied to a specific harassment pattern

A weak moderation list has a vague reason:

  • bad people
  • annoying accounts
  • accounts I disagree with
  • people from an old argument
  • accounts someone else dislikes

I am not trying to judge the list creator. I am deciding whether the list gives me enough information to act from my account.

When the reason is clear, member review is faster. I can remove accounts that do not match the reason and keep the accounts that do.

When the reason is vague, I usually stop. A fork should make my moderation decisions easier to explain, not harder.

Keep the source link

I keep the original list URL in the fork description.

The tool suggests text like this:

Source: https://bsky.app/profile/example.com/lists/3abc123
Forked from Example List by @example.com.

Leave that in.

Future you needs to know where the fork came from. If the list becomes stale, or if someone asks why an account is included, the source link saves guesswork.

I also add one short line for my reason:

Edited for: spam accounts I do not want in replies. Removed accounts where the evidence was unclear.

Nothing fancy. Just enough to remember what I meant.

Remove accounts before muting or blocking

The useful part of forking is the removal step.

I remove accounts when:

  • the bio or recent posts do not match the list reason
  • the source list is old and the account has changed
  • the account was included because of a one-time argument
  • the account is a news source, archive, or bot I still want to read
  • I cannot explain why I would mute or block it

My standard is simple: I need to be willing to apply the action from my own account.

If I cannot explain the action, I remove the account from the fork.

Search the list by category

For a large moderation list, I search before I scroll.

Useful searches:

  • bot
  • news
  • archive
  • official
  • a city or country name
  • a topic I still want to follow
  • a handle fragment for accounts I recognize

Search is faster than trying to review 1,000 accounts in order. It also catches the false positives I care about most.

If the list is still too big to review, I do not use it. A moderation action I cannot inspect is not useful to me.

Keep a smaller fork when needed

I would rather create a smaller fork than keep a huge list I barely understand.

For example, a 900-account source list might contain several groups:

  • spam accounts I definitely want muted
  • political accounts I still want to read for context
  • news accounts that were added during a noisy event
  • personal accounts that look like one-off conflict entries

Those do not all need the same action.

In that case I make a tighter fork with the accounts I can explain. The rest can stay out. I can always revisit the source list later and create a second fork for a different reason.

Small moderation lists are easier to maintain. They are also easier to undo when the original problem fades.

Mute first when you are unsure

Bluesky moderation is layered.

The official labels and moderation guide describes moderation as multiple stackable systems: network takedowns, labels from moderation services, and user controls such as mutes and blocks.

For my own account, I usually start with the lighter action.

I also separate the fork decision from the action decision.

Creating a fork only says, "These are the accounts I reviewed together." Muting or blocking says, "Apply this account-level control now."

That separation helps when I am using someone else's list as research. I can create the fork, leave it unmuted for a short review pass, and only apply the action after I am comfortable with the member set.

When I am tired, annoyed, or reacting to a pile-on, I stop at the fork. Moderation decisions are easier when I am not trying to win an argument in real time.

Mute is good when:

  • the issue is noise
  • I do not want the accounts in my feed
  • I may want to revisit the list later
  • I do not need a public block signal

Block is stronger. I use it when I want the account-level boundary, not just a quieter feed.

The official user-list docs make one practical distinction clear: list mute state is private, while list blocks are public records. I pause before blocking a whole fork because the public record is part of the action.

Review the fork after it runs

A moderation fork is not finished when the create button succeeds.

I check it again later:

  • after a week
  • after the event or spam wave ends
  • when the source list changes
  • when I notice missing context
  • before I recommend the fork to anyone else

Moderation lists get stale for normal reasons. People change accounts, spammers rotate handles, and communities cool down after a fight. A useful moderation list can become too broad if nobody reviews it.

The cleanup is simple:

  1. Open the fork.
  2. Search for obvious false positives.
  3. Remove accounts that no longer match the reason.
  4. Decide whether mute is still enough.
  5. Keep the source note in the description.

That is all I need from a moderation fork: source, reason, review, action.

My default workflow

Here is the version I use:

  1. Paste the source moderation list into Fork a Bluesky Moderation List.
  2. Confirm it is a modlist.
  3. Read the source description.
  4. Keep the source URL in the fork description.
  5. Search for accounts I would not mute or block.
  6. Remove bad fits.
  7. Create the fork under my Bluesky account.
  8. Mute first unless I am sure I want a block list.
  9. Review the fork after a week.

The original list does the discovery work. The fork makes the decision mine.

Last updated: June 12, 2026