FR#150 – On ICE, Verification, and Presence As Harm

The U.S. Immigration and Customs Enforcement, ICE, became one of the most-blocked accounts on Bluesky within days of receiving its verification badge handed out by Bluesky PBC. The account itself has not posted anything, because it does not need to, with the presence being the point. ICE joining Bluesky was part of a moment in November 2025 where the US regime decided to antagonize the ATProto network by having multiple organisations, including the White House, join the network. They quickly lost interest again however, and most accounts have not posted anything over the last two months.

The decision by Bluesky PBC to verify the ICE account, two months after registration and without the account being active, lead to quite different responses for the fediverse and for the ATmosphere. On the fediverse, the choice by Bluesky PBC to lend legitimacy to ICE was a final nail in the coffin, with loud declarations to disconnect from Bluesky and block the bridge between these two networking protocols. Mastodon founder Eugen Rochko was the most notable account, who publicly declared to disconnect from the bridge.

Within the ATmosphere, the response focused on two parts, both a frustration with Bluesky PBC verifying the ICE account, as well as a call to block the account en-masse, which led to the ICE account quickly becoming one of the most-blocked accounts on the network.

The difference in response between the networks provide an insight in how both the ActivityPub network and the AT Protocol network have very different underlying assumptions, where these obscure difference in network architecture lead to diverging outcomes in social structure and behaviour.

In the ActivityPub model, servers are understood as opinionated communities or places, that choose to connect with other communities. Federation is optional and based on a match in values between the connecting servers. This value-question is baked into it’s network structure, and makes it clear that every individual server is a non-neutral place.

(As a side-note, the fediverse as-it-exists struggles with this model, with Mastodon being uncomfortably stuck between the marketing material promoting a network-of-communities with shared values, but the software having a deeply ingrained mental model of ‘lets-federate-with-everyone’, which in itself explains a fair amount of conflict in the fediverse over the years).

ATProto takes a different approach, by separating the base layer of data storage from the application layer. The base data storage layer is designed to be neutral infrastructure, where data lives in Personal Data Servers. This data is ‘neutral’, in the sense that it is permisionless and anyone can set up a PDS without permission. The applications built on top of that infrastructure are assumed to be opinionated and not neutral. Every ATProto application takes a subset of the entire network of data, and can be opinionated about what they surface and to whom they present this.

This creates a sense of ‘neutrality’ at the base layer (hello to all the people whose eyes start twitching every time they read the claim that social software can ever be neutral), with value-based and opinionated apps build on top of this base layer.

When fediverse users say they don’t want to be bridged to Bluesky, they’re applying an ActivityPub mental model to ATProto infrastructure. In one sense this is a bit of a category error, the bridge connects to networking infrastructure, not the application. This way your’e not just refusing to federate with the Bluesky-the-app but with the entire ecosystem, including apps with different values, such as Blacksky or Leaflet.

But in another sense, this shows the issue with bridging between these two networks, and how this is not just a matter of networking architecture, but of how network architecture leads to different mental models that are not always compatible with each other.

The choice by Bluesky PBC to give ICE a verification checkmark shows that while the company has built systems that enable the ‘neutral infra, opinionated apps’ model, their operational choices fall back to a 2010s mental model where the platform itself is the neutral ground, where everyone, including Trump, is welcome.

Bluesky’s Community Guidelines lists the two major principles as ‘Safety First’ and ‘Respect Others’. It is somewhat unclear how the presence of a fascist police force that is actively working to instigate civil war aligns with the principles of safety and respect that Bluesky supposedly champions.

When it comes to actual rules in the guidelines, it is all about user behaviour and the content on Bluesky. The problem is that it is the presence of ICE itself that is already causing the harm. The intimidation of ‘we are here, you cannot escape us’ is the point, and the accounts by the regime are deliberately trying to provoke an outrage. The account doesn’t need to post anything that violates the rules because the intimidation is the presence itself. Bluesky’s Community Guidelines emerged from a moderation paradigm that moderates content (its called content moderation for a reason), and has a structural blind spot for presence-as-speech. Fascists intuitively understand this difference, and are skilled at exploiting it.

The problem is that there is no easy fix for this either. Bluesky board member Mike Masnick formulated this as Masnick’s Impossibility Theorem: Content Moderation At Scale Is Impossible To Do Well. And if content moderation on a platform is already impossible to do well at scale, it is even more impossible to do well at scale when off-platform behaviour were to be considered. Which makes it understandable why a Trust & Safety team would not want to consider off-platform behaviour when enforcing rules.

But Bluesky’s own open protocol makes this all the more difficult the further the network grows. If a fascist publishes a nazi blog under the standard.site lexicon on their own self-hosted PDS, should Bluesky PBC let this account use their Bluesky app? According to the current Community Guidelines the answer is yes: “These Guidelines only apply to social networking that happens on Bluesky. If you’re using another social networking application on the AT Protocol that isn’t Bluesky Social (a “Developer Application”), the terms and conditions of that Developer Application will govern your experience. We are not responsible for the content or practices of Developer Applications.”

The fundamental problem is that the way Bluesky is set up, both the company and the app, it is virtually impossible to do moderation that takes off-platform behaviour into account. But if you don’t take off-platform behaviour into account, your principles in the Community Guidelines of Safety and Respect lose their meaning.

The second issue here is that not only let Bluesky have ICE have an account, but that they felt the need to verify this account, after the account had been dormant for a while. Verifications via checkmarks are ostensibly to prevent against misinformation and impersonation, but in practice their main use case is to signal social status, endorsed by the verifier.

Bluesky’s verification system was explicitly designed to distribute trust rather than concentrate it. When launching the system in April 2025, the company wrote that trust “emerges from relationships, communities, and shared context,” not just top-down from platforms. The Trusted Verifiers feature allows independent organizations to issue verification badges directly.

This design of the verification system is a good example of the infrastructure/application separation of ATProto, where verification doesn’t have to be a network-wide decision made by Bluesky PBC. Instead the system allows for multiple verification sources with different values and criteria, letting users decide which verifiers they trust.

For government accounts, Bluesky had options. They could have delegated verification to a news organization, a government accountability group, or some other entity willing to take on that role. They could have let ICE exist as an unverified account, authenticated only by its domain handle. Instead, after nearly two months of apparent deliberation, Bluesky PBC verified ICE directly.

Bluesky PBC built a system designed precisely for moments like this, where verification decisions could be distributed and delegated to other actors, rather than centralized. And then, the first time it could have meaningfully applied that distinction, the company defaulted to acting like the platform that decides who gets legitimacy, where they themselves wanted to be the ones that verified ICE.

Let’s be clear here: ICE is conducting a reign of terror, committing excessive violence and murder, with the blessing of the state for its officers to not be bound to the law, with the explicit purpose of baiting people into committing violent responses and stoke the flames and possibility of civil war. The very presence of ICE is to cause terror.

And if your social networking guidelines say “sorry we can’t do anything about this”, something has gone pretty wrong somewhere, in a way that goes beyond just this individual decision itself.

So when fediverse people apply an ActivityPub-style mental model of networked communities to an ATProto model that separates infrastructure from application, how wrong exactly is that, when the company that has built the tools for that distinction does not operate according to them when the pressure is on?

The case of ICE shows two unresolved problems that will only intensify as the ecosystem grows: how to deal with abusive behaviour that happens outside of the app (and especially if it happens outside of the app but on-protocol) but causes harm on it, and how in a world where fascism is a real and existential threat, harms on social networks have evolved from not only being content-based but also being presence-based.

#nlnet

connectedplaces.online/reports…