Bluesky DDOS Attacks
I was attempting to check my feed the other morning, only to be met with a rather stubborn "Rate Limit Exceeded" error. As it turns out, Bluesky was weathering a highly sophisticated Distributed Denial-of-Service (DDoS) attack that overwhelmed its API servers. Naturally, the main application went dark. But what was somewhat more interesting to me was the collateral damage: users on independent, third-party servers—specifically the European-based Eurosky—were also knocked entirely offline.
The marketing around decentralised networks like Bluesky’s AT Protocol promises a sort of ecstatic resilience. The theory goes that because we are no longer tethered to a single corporate monolith, a failure in one node simply means the network routes around it. Eurosky users, who explicitly migrated their accounts to EU-hosted servers to escape the hegemony of US-based "Big Tech" infrastructure, felt insulated by this premise. Yet, when Bluesky PBC's servers timed out, Eurosky went dark too.
To understand the failure, we need to look at the underlying mechanics. The AT Protocol doesn't just copy a massive database to a thousand different servers. Instead, it unbundles the traditional functions of a social network into distinct, interchangeable layers:
- The Personal Data Server (PDS): This is your home base. It hosts your actual data—your posts, likes, follows, and cryptographic keys. Eurosky operates purely as a PDS, storing data on Hetzner servers in Germany to comply with European privacy laws.
- The Relay: The heavy lifter. Relays crawl all the disparate PDSs across the network, aggregating their updates into one massive, continuous "firehose" of data.
- The AppView: This is the crucial prism. It consumes the raw firehose and processes it into a readable state by counting likes, assembling reply threads, and enforcing moderation blocks.
- The Client: The application interface you actually tap on, which requests your rendered feed from the AppView.
Herein lies the complexity trap. While the AT Protocol is fundamentally open, operating an AppView or a Relay at global scale requires serious, enterprise-level infrastructure and funding. Running a PDS like Eurosky is relatively cheap; indexing the entire network's firehose is not. Consequently, true decentralisation at the infrastructure layer hasn't quite materialised. As of early 2026, almost the entire ecosystem still relies on Bluesky PBC as the sole operator of a full-network AppView.
When the DDoS attack hit on April 15 and 16, it choked Bluesky’s core API servers (api.pop1.bsky.app and api.pop2.bsky.app). Eurosky’s own PDS infrastructure remained perfectly operational—no user data was lost, and actions were still safely saved to local repositories. However, the umbilical cord connecting Eurosky’s data to Bluesky’s downstream AppView was severed. Because client apps rely on that centralised AppView to figure out what to display, Eurosky users were left flying blind, entirely unable to load their feeds.
It’s a bit of a mixed bag. On one hand, we have successfully decentralized the "speech" layer—users genuinely own their data and control where it lives. On the other hand, the "reach" layer—the expensive plumbing required to aggregate and deliver that data—remains heavily centralised.
Following the outage, Eurosky announced a crowdfunding initiative to build its own independent European AppView backend. It’s a necessary step. Until the ecosystem develops redundant, commercially sustainable infrastructure at every layer, we are reminded that decentralisation is not a binary state. It's a messy, ongoing transition, and right now, we are all still relying on the exact same set of pipes.