federation-across-networks

The Bridge to Bluesky: What Happens When Two Protocols Try to Talk

Part 1 of the "Federation Across Networks" mini-series - a continuation of the "Exploring the Fediverse" umbrella series.

Federated Mind

— 10 min read
Share
Data flowing from the left side depicted in blue with a blue butterfly depicting Bluesky traffic flowing into a glowing orb in the middle. On the right side is data depicted in purple along w
The Bridge between Bluesky & Mastodon

The last post in this series closed with a question: do the governance choices that define Mastodon communities stay contained to Mastodon? The answer is no. When Mastodon meets Bluesky, those questions surface again in a new form: consent, moderation, who gets to decide what crosses which border.

This is the story of what happens at that border.

How Bluesky got here

Bluesky started inside Twitter in 2019 as a funded research initiative to develop an open and decentralized standard for social media. Jack Dorsey, then Twitter's CEO, announced it with the stated ambition that Twitter itself might eventually migrate onto whatever protocol emerged from the work.

The migration never happened. Bluesky spun out as an independent company before Elon Musk's acquisition of Twitter closed in 2022. It launched its AT Protocol in 2023 and opened to general registration in February 2024, adding 1.5 million users in a matter of days. By late 2025 it had crossed 40 million registered users, with third-party estimates putting monthly active users in the low tens of millions by early 2026.

Twitter/X

What it didn't do, and what critics in the fediverse community never stopped pointing out, was adopt ActivityPub. Bluesky built an entirely new protocol instead of using the existing standard that powers Mastodon, Pixelfed, PeerTube, and most of the rest of the federated web. Evan Prodromou, one of ActivityPub's co-authors, was direct: "The best thing that [Bluesky] can do for its users is implement ActivityPub to connect to the millions of users on the fediverse."

Bluesky's position was that ActivityPub couldn't do what they needed. Account portability (the ability to move your entire identity, including follows and post history, to a different server without the old server's cooperation) isn't something ActivityPub handles cleanly. Neither is global-scale content aggregation, or composable moderation that can be layered on top of the protocol itself. These were architectural requirements, not diplomatic deflections.

Dorsey, for his part, eventually lost interest and pivoted to backing Nostr, yet another protocol, more radically decentralized. He resigned from Bluesky's board in 2024. The company now operates under CEO Jay Graber CEO Toni Schneider (thanks to Kuba on Bluesky for correcting me on this), independent of both Twitter's lineage and Dorsey's ideological trajectory. As of January 2026, AT Protocol is in the process of standardization within the IETF (Internet Engineering Task Force), moving from a company-led spec toward broader institutional backing. ActivityPub, by contrast, has been a W3C standard since 2018; Mastodon had been running on it for three years before Bluesky announced it was building something new.

Two protocols, two bets

AT Protocol and ActivityPub were built from different premises about what decentralized social networking should optimize for.

AT Protocol optimizes for portability and scale. Your identity is anchored to a domain name you own: your handle can be your actual website (@yourname.com) rather than a server-assigned address. Your content lives in a Personal Data Server (PDS) that can move between hosting providers without the old provider's cooperation. The network aggregates everything through a global relay, a firehose of all public content available to any application built on the protocol. All current interactions on AT Protocol are treated as public records: posts, likes, and even block relationships are enumerable, including your block lists.

ActivityPub optimizes for community autonomy. Your server is your community: the instance you join sets the moderation culture, the defederation policy, the norms of the space. Servers communicate directly with each other in a federated mesh rather than through a central relay. Small communities can run on modest hardware. The tradeoff is that your posts are bound to your instance; if it shuts down, your posts go with it. Migration tools can preserve your follower graph when you move between live instances, but if the old server disappears before you migrate, those followers are gone with it.

Neither of these is the wrong bet. They reflect different priorities. AT Protocol was built to solve the problems that plagued Twitter at scale: data portability, algorithmic transparency, the ability to switch clients without losing your social graph. ActivityPub was built to solve the problems of platform capture: giving communities the ability to govern themselves without a central authority that can change the rules.

The incompatibility between them is structural, not incidental. AT Protocol runs on a global firehose architecture; ActivityPub runs on point-to-point server federation. Reconciling those topologies requires translation, not just a handshake. Which is why, instead of native interoperability, what we have is a bridge.

Conceptual architecture of both protocols. AT Protocol's relay layer on the left vs ActivityPub's federated mesh on the right.
Conceptual architecture: AT Protocol's relay layer (left) vs ActivityPub's federated mesh (right). Both support variations — this illustrates the dominant pattern, not the only one.

The bridge

Bridgy Fed was built by Ryan Barrett, an independent developer who has spent over a decade building tools that connect different corners of the web. The project now sits under A New Social, a nonprofit focused on cross-protocol interoperability. It has no affiliation with Bluesky or Mastodon.

The setup is deliberately simple. From Mastodon, search for and follow @bsky.brid.gy@bsky.brid.gy. The account follows you back, and your Mastodon account becomes discoverable on Bluesky. From Bluesky, follow @ap.brid.gy, and the same thing happens in reverse. Your bridged handle has an ungainly suffix that makes the seam visible; a Mastodon user on Bluesky appears as @username.instance.ap.brid.gy. The interactions still cross: follows, posts, likes, replies.

If you want the step-by-step on how to set this up, the EFF's April 2026 guide covers every configuration in plain language: Mastodon to Bluesky, Bluesky to Mastodon, Threads into both, and even bridging a personal website. What started as a developer experiment is now mainstream enough for EFF to write a how-to.

For the technically adventurous, there's also Fedisky, an ActivityPub sidecar for a self-hosted AT Protocol PDS. Where Bridgy Fed is a service you use, Fedisky is infrastructure you run. It requires operating your own Bluesky PDS instance, which puts it out of reach for most people. Bluesky's own docs have featured Bridgy Fed as a community project, signaling that the AT Protocol team is supportive of the bridge even without building it themselves.

Bridgy Fed is bidirectional between open protocols. A different category of bridge goes one-way into the fediverse from closed platforms. Bird.makeup lets you follow public X/Twitter accounts from Mastodon. Search for @username@bird.makeup and their posts appear in your fediverse feed without an X account. Kilogram.makeup does the same for Instagram; hacker.makeup for Hacker News. These are read-only windows: content flows in from the closed platform, but you can't reply back across. They're not solving the AT Protocol ↔ ActivityPub problem, but they answer a different question: how do you stay in one place and still see what's happening everywhere else.

The longer-term answer to the bridge problem may not be a bridge at all. WordPress.com now supports both ActivityPub and AT Protocol via official first-party plugins, so a single site can publish natively into both networks without using third-party bridge services like Bridgy Fed. Ghost, which this publication runs on, already federates via ActivityPub and has announced Bluesky support. When a platform natively speaks both protocols, the translation layer disappears. Your post just goes both places, closer to how email works across different providers than what a bridge has to do.

This is the POSSE philosophy from the IndieWeb movement: Publish (on your) Own Site, Syndicate Elsewhere. Post once to a platform you control, let it reach every network. Bridgy Fed is a workaround that gets you POSSE behavior from an existing social account. Platform-native dual protocol support (Ghost, WordPress) is the same idea without the workaround.

What crosses, what doesn't

Posts cross. Follows cross. Likes and reposts cross. Replies mostly cross, though they can be delayed or dropped depending on how each side of the bridge is configured.

Edited posts don't re-sync. Mastodon supports editing natively, but Bluesky doesn't, so if you edit a bridged post on Mastodon, the Bluesky copy won't automatically update. Direct messages don't cross; the protocols handle private messaging differently enough that bridging them isn't currently supported. Quote posts from Mastodon don't bridge to Bluesky yet, due to differences in how each side implements the feature.

Block behavior has been the most structurally incompatible piece, and it's where A New Social has been doing the most active work. On AT Protocol, blocks are entirely public and enumerable: anyone can query who has blocked whom. On ActivityPub, the privacy model is more nuanced. A New Social launched domain blocklists in January 2026, bringing fediverse-style domain blocks across to the AT Protocol side, and integrated ATProto blocklists in late 2025 so Bluesky-style community blocklists carry through to the fediverse. Cross-protocol block synchronization is now part of Bounce, A New Social's migration tool: when you move between protocols, your moderation decisions move with you. The structural incompatibility hasn't fully resolved, but the gap is actively narrowing.

Some Mastodon instances have chosen to block Bridgy Fed's domain entirely. Users on those instances can't be bridged at all, and Bluesky users can't reach them through the bridge. This is a deliberate governance decision by those instance operators, the same kind of defederation call that defines community management on Mastodon. Usernames containing characters that aren't valid in Bluesky handles (such as _ or ~) get normalized when bridged: those characters are mapped to - in the bridged handle, which can make the seam even more visible.

The bridge is a suspension bridge over rough water, not a highway. It works reliably for basic interactions, has known gaps, and requires some tolerance for the seams showing.

In February 2024, before Bridgy Fed had launched its Bluesky bridge publicly, Ryan Barrett announced his plan for the default behavior. Public Mastodon posts would become visible on Bluesky without authors doing anything: an opt-out model where users who didn't want to be bridged would need to explicitly signal that.

The reaction from parts of the Mastodon community was immediate and intense. Barrett told TechCrunch: "It hasn't been easy the last couple of days, being the main character of the fediverse." The GitHub issue tracking the objections, titled "Opt-out is a terrible default and should be reconsidered," accumulated hundreds of comments, including legal threats and personal attacks that Barrett described as unlike anything he'd encountered in 12 years of working on similar tools.

The underlying argument wasn't frivolous. A significant portion of Mastodon's user base had arrived specifically to escape centralized platforms, some after experiencing harassment, abuse, or stalking that made the smaller, governed fediverse feel meaningfully safer. For those users, having their posts automatically visible on Bluesky without their knowledge felt like the border they'd crossed to get there was being erased.

Barrett was sympathetic: "A lot of the people there came from more traditional centralized social networks and got mistreated and abused there... They expect consent for anything they do with their data."

He also pushed back on a widespread misreading of the bridge's mechanics. The opt-out model wasn't going to flood Bluesky with every Mastodon post simultaneously. "It only does that when someone first requests to follow a person across the bridge" he said. A lot of the anger was aimed at behavior the bridge would never have exhibited.

The resolution Barrett landed on is a "discoverable opt-in." When a Bluesky user first tries to follow a Mastodon account through the bridge, the Mastodon user gets a DM asking whether they want to be bridged. They can say yes, say no, or ignore it. The bridge only activates with explicit consent.

Bridgy Fed consent flow diagram
The current Bridgy Fed consent flow. Ignoring the DM leaves the account unbridged.

 

Mastodon founder Eugen Rochko publicly opted his own account out of the bridge in January 2026, signaling that even as the tooling matured and reached mainstream use, the ideological tension hadn't fully resolved.

The question travels with the protocol

Governance Is the New Differentiator argued that moderation policy and AI stance had become the real reason to choose one Mastodon server over another: governance was the differentiating feature, not UX or server size. The same dynamic surfaces here, at the protocol border rather than the instance level.

Whose moderation rules apply when a post crosses from ActivityPub to AT Protocol? If a user has been defederated from large portions of the Mastodon network, blocked at the instance level by dozens of servers, those block decisions don't carry through the bridge. On Bluesky, that user may have full reach. A suspension on one side of the bridge is not a suspension on the other.

This isn't a flaw in Bridgy Fed's implementation. It's a consequence of two different communities having built two different sets of norms for acceptable behavior, and those norm sets not translating automatically. The bridge moves content. It doesn't, and can't, enforce that the rules travel with it.

What the bridge is actually for

The bridge to Bluesky exists, works, and takes about two minutes to activate from either side. The rough edges (ungainly usernames, lost edits, incomplete block portability, occasional dropped replies) are real and worth knowing about before you use it.

The deeper question the bridge raises isn't technical. ActivityPub and AT Protocol aren't two implementations of the same idea. They're two different ideas about what decentralized social should be, different bets on what matters most, made by different people for different reasons. The bridge connects them. It doesn't reconcile them.

If you're mapping your options on the open web and want to start somewhere concrete, the Fediverse Quick-Start Checklist covers the first steps on both Mastodon and Bluesky.

Next: Threads enters the fediverse. The difference from Bridgy Fed is significant: this isn't an independent developer building a bridge in their spare time - it's Meta.

References

CTA Image

Subscribe to get Part 2 delivered directly to your mailbox.

Subscribe

Read more