jack's blog

Building Beyond Bluesky's Backend

how atproto's biggest champion could also be its biggest risk

September 29, 2025

I've recently had the on and off feeling of bursts of excitement with new atproto apps and projects, then the feeling of it never taking off for multiple reasons (won't jump into them now).

Then @huwupy.kawaii.social posted this on Bluesky which caused me to go off on a bit of a thread:

πŸ…πŸ₯”πŸ«πŸŒ½ hoopy frood 🌢️ πŸ₯‘πŸ«πŸŒ΅'s avatar
πŸ…πŸ₯”πŸ«πŸŒ½ hoopy frood 🌢️ πŸ₯‘πŸ«πŸŒ΅
4mo

really really annoyed that so many people here have Platform Brain, to the degree that the company has it now. Platform Thinking won. ATProto is a platform now. I don’t make the rules

key terms

Before I dive into different aspects of the current situation, I want to have some of the keywords here and a summary of what they are (to help you see the choke point further below). A lot of people reading this will know about atproto already so can skip! @mackuba.eu has written up a good post on this in much more depth though, you can read that if you want too!

  • Relay - the service that merges firehoses from individual PDSs into one network-wide stream (you can ingest this with Bluesky's firehose service "rainbow")

  • AppView - the "read API" that ingests data from the Relay and aggregates it to serve clients (this is what builds your timeline and can return a post's like count for example)

  • CDN - Serves copies of blobs (images/videos) that records reference; blobs are stored on the PDS, delivered to clients via the CDN for speed and efficiency.

  • PDS - (Personal Data Server) the source of truth for all your atproto app data, all public, emits your repo's change stream. For example, when you post on Bluesky, the record is stored in the PDS and sends an event on its firehose.

atproto without bluesky?

This is hard to imagine. Right now, Bluesky is the core of the atproto ecosystem. 99%+ of users are on Bluesky-hosted PDSs, using the official Bluesky iOS/Android/Web app and are using a .bsky.social handle. This is ok as there's always the right to leave, and this is becoming more accessible. The issue is that atproto beyond a Twitter clone is only used by power users.

"atproto beyond a twitter clone" meaning atproto apps that aren't Bluesky, but does not refer to the apps such as Skylight and Flashes. These apps are using Bluesky CDNs, and more importantly, Bluesky's AppView.

In the past ~2 weeks it feels like people within the atproto community on Bluesky have noted the issues with the AppView (or at least seen issues arise.) The issue is that these are too costly right now. The costs have shrunk a ton, don't get me wrong! But, for a regular non-atproto dev building a new social app, would you:

  • spend money + more time setting up own AppView + CDN for more long-term sustainability of the network (also requiring their own moderation!)?

  • use the Bluesky-hosted API (AppView) + CDN for free?

Most will likely go for the latter. I can't blame them, there's not enough reason to spend the money on this at the moment.

My issue currently is that the Bluesky team frequently mention apps like Skylight and Flashes as if they are their own entire applications + backend built on the same protocol. This is partially correct, but they are still hosting images, etc on the Bluesky CDN + use the Bluesky-hosted AppView. Progress is happening here, and they plan to move to their own infrastructure, but this is all in the future.

For example, this is an example of an atproto app using the Bluesky CDN:

jack's avatar
jack
4mo

also i noticed that @grain.social is using Bluesky's CDN to host images - are there any plans to change this? will help improve decentralisation imo

Screenshot of one of my photos from Grain (grain.social) opened in a new tab, revealing that the images are hosted on `cdn.bsky.app` under the user's account

the point?

Currently this still feels early on. The AT Protocol is still operated by Bluesky PBC (the company), AppView costs are still coming down, and many users are yet to come!

However, this all feels a little useless if all these other apps are going to just act as a client for Bluesky, presenting this content in some other way.

In my head there's a balance between an app hosting their own infrastructure and only being used by a niche set of power users, and something more mainstream like Bluesky, but then bootstrapping happening around that.

This post is a little short but I just think that all these apps using the Bluesky-hosted backend infrastructure and growing because of it isn't necessarily great for the health of the network. I can see why it would be done in an earlier stage for apps, and I'm looking forward to the ever-shrinking costs of spinning up vital infrastructure such as more Relays, AppViews and CDNs.

Unsure how exactly this could be done but I just wanted to collect my thoughts in this quick post. I'll likely update this over time, or create more Leaflets about this.

message to app devs

I've mentioned Skylight and Flashes here, and don't get me wrong, the developers behind these two apps are awesome! They're undeniably much better than their centralised counterparts, but I just wanted to point out some more-known examples.

I get that these developers are working their asses off to get them usable, and by no means have evil intentions by using this "third party" (from their perspective) infrastructure. It just makes sense at the moment.

what if the worst were to happen?

Note: this is all extremely theoretical and is very unlikely. This is just an extreme of one end.

Bluesky is an app that operates across the globe. Turkey have already stepped in to ban accounts on Bluesky, however a lot of these posts were just hidden from Turkey as a region (using this labeller) meaning that third party Bluesky clients could show this content. However, what if a Government requested further? This wasn't enough, and citizens were using VPNs & third party clients to bypass this censorship. Then, Bluesky PBC could, in theory, start banning accounts from their AppView. This means these accounts would be hidden in any apps that use this as the API backend.

This would also mean that any users on Flashes or Skylight (again, in these apps' current state) would be further banned from these two without understanding.

Again, this situation isn't happening right now, and is extremely theoretical. Paul has stated that AppView-level bans should only be taken on extreme spam/illegal content. This reply shows that he wants moderation to primarily be applied through in-app labels:

Paul Frazee's avatar
Paul Frazee
5mo

I can tell you that the intent of the design is that the appview applies labels, primarily in the client, but at times at the API when needed. I need to find out what PDS-level takedowns we're doing, and whether there needs to be any adjustments there.

what's next?

I just want to reiterate that I currently don't blame these app developers for leveraging the Bluesky infrastructure the way they are at the moment.

Currently I'm hoping that the cost to run an AppView is seriously cut down. Tools like Slices are helping bring this down (e.g. by ignoring some other information from posts to make it more efficient).

Moderation is still difficult, though. You obviously don't want bad content circulating your application. Many of the developers behind these apps are indie devs who can't afford the tools required for moderation.

Sebastian (developer behind Flashes, Skeets and Bluescreen) highlights this issue here:

Screenshot of a reply to my post: "It’s a matter of moderation. Custom lexicons require moderation by someone else but @bsky.app. Thereβ€˜s a reason I currently have 6 super awesome #ATProto apps by talented devs in my TestFlight which are not being released to the App Store. I hope we can solve this with #CoCoMo at @eurosky.social " (by Sebastian - @seabass.bsky.social)

At EuroSky they seem to be planning some tool for sharing moderation infrastructure between atproto applications. As I understand it, the idea is an app developer would approach EuroSky with a demo of their app, and if meeting some sort of criteria they could have their content moderated for them. This might seem unreliable or another single point of failure, but the developer could always step away and switch (although I'm unsure what to at the moment.)

This would theoretically be financed through grants, and would benefit the whole ATmosphere (atproto network.)

Furthermore, Bluesky has registered as a "Partner" to ROOST. ROOST are a new company/organisation (I'm unsure) that are making moderation more accessible to developers. They don't seem to be open yet (correct me if I'm wrong), but Juliet Shen showed a demo at a recent #ATProto_NYC conference where she was live-moderating posts with a local gpt-oss-20b model:

dapurplesharpie's avatar
dapurplesharpie
5mo

@julietshen.bsky.social says her original HACKATHON app failed, but she's gonna show off more of the @roost.tools features

@julietshen.bsky.social showing off @roost.tools at #ATProto_NYC

If I recall, this wasn't officially a ROOST tool, but is an example of what could happen.

I'm unsure what else could be done moderation-wise at the moment, @ me on Bluesky if I'm missing anything!

recap

In summary, many new atproto applications are building with Bluesky-owned APIs (via their AppView) (+ Relay + CDN beyond that). This is ok as it's still on top of atproto and accessible anywhere in the ATmophere, but isn't fully distributed as it's still reliant upon Bluesky PBC. Work is still being done on lowering moderation, infrastructure and scaling costs, but in the mean time community + shared efforts seem to be the way to go (look at what EuroSky is planning.)

Currently this isn't causing any major issues, but there have been some dodgy moderation actions taken on the Bluesky app, and it would suck for this to affect the rest of the ecosystem. What do you think developers should be thinking about?

Subscribe to jack's blog
to get updates in Reader, RSS, or via Bluesky Feed
Using Tailscale to Get Around Network Restrictions
Awe Dropping, or.. Dropping? - Apple Event September 9, 2025