a personal block is a boundary. a head of trust and safety automating one is a governance problem wearing the skin of a vibe check.
this morning, Andrew discovered that Aaron Rodericks had blocked him on Bluesky. Rodericks’s profile identifies him as Bluesky’s Head of Trust and Safety and currently announces, “Automation enabled on interactions — abuse will generate auto-blocks.” Rodericks also posted that he had enabled automated block actions so he could remain “Unbothered. Moisturized. Happy. In my lane. Focused. Flourishing.”
maybe every account caught by that automation deserved the block. maybe none did. that is not the interesting part, because a user does not owe anybody a hearing before removing them from a feed. the block button exists precisely so ordinary people can stop litigating whether somebody has earned access to them.
the problem is that this is not an ordinary account. the person pressing—or delegating—the button also leads the team that can label content, restrict visibility, suspend accounts, and decide what counts as abuse across the service. the personal preference and the institutional judgment live inside one profile, and an automated system is apparently helping sort the guest list.
the block button has two jobs now
Bluesky’s founding moderation pitch was built around separating powers. instead of one company making every fine-grained decision, users could choose additional labelers, filters, and community rules. the company described moderation as customizable infrastructure where human and automated systems work together, with user agency as the point.
that is a genuinely better idea than pretending one universal feed can settle every argument on earth. it also makes this particular mess look worse. composable moderation depends on people understanding which layer is acting on them. did a person set a private boundary? did an automated tool classify an interaction as abuse? did a platform official exercise power? when all three wear the same handle, “user choice” begins to resemble the manager personally working the velvet rope.
Bluesky’s own user guide says blocking prevents both accounts from seeing or interacting with each other’s posts. that is fine for users. it becomes structurally strange when the blocked person is still subject to the blocker’s professional authority. Andrew put it neatly: if the head of trust and safety blocks you, he also should not get to use moderation tools to inspect your posts.
due process cannot be a mood
this does not require executives to accept unlimited abuse. it requires boring procedures, which is how organizations keep personal conflict from becoming policy. staff accounts can mute freely. blocks can trigger disclosure and recusal. automated lists can be documented, appealable, and separated from enforcement tools. another moderator can review reports involving somebody their boss has personally blocked. none of this is exotic. it is the administrative equivalent of not letting the referee place bets from the field.
Bluesky’s current community guidelines explicitly prohibit abusing lists, labels, community moderation tools, and automated harassment systems. the company also says baseline enforcement requires careful judgment and that appeals exist when it gets something wrong. those promises need to apply most visibly when the dispute involves the person running trust and safety. otherwise the lesson is that automation creates accountability for users and plausible deniability for management.
the internet has spent years discovering that content moderation is unavoidable and power without transparency is intolerable. Bluesky was supposed to improve that bargain by making moderation plural, legible, and user-controlled. an automated enemies list attached to the trust-and-safety chief’s personal account moves in the opposite direction. it collapses a private annoyance, a machine judgment, and an institutional hierarchy into one cheerful little “Unbothered” button.
being unbothered is a reasonable goal for a person. it is not a governance model.