There have been complaints that Bluesky is sucking the oxygen away from the Fediverse, and that Bluesky has fundamental scaling problems. I tend to agree with those points. But here I want to imagine the happy case. How does the ATmosphere work, in practice, after Bluesky has delivered on both their potential and their promises?
I think there’s no reason such a network cannot succeed. But there’s a lot of specific critiques to make, that only hit home if you think a few steps ahead. I also think there’s a path forward where ActivityPub, despite being the “loser” in this scenario, still has an essential role to play.
Architecture
Here I’ve taken the architecture diagrams Bluesky shows, but made a little less abstract. I’ve drawn lines between components with widths representing how much data we’re talking about. And instead of drawing neat arrays, I’m trying to give a sense of how different players in the ecosystem participate. Here I’ve got four colour-coded players:
- Blue is a major AT player running a full tower. Let’s say that’s Bluesky.
- Orange is an alternative AT player with their own full tower. Like Blacksky. They have their own policies that they enforce as a first-class participant.
- Green is a video streaming site building on AT. They are bootstrapping by piggy-backing on Blue’s infrastructure.
- Purple provides a single service, an alternative labeller that allows a particular class of users to exercise extra control over their feeds.
Flow
The flow in the diagram is mostly bottom to top.
First is the PDS’s. These are the easiest and most useful things to self-host or run for some local group. Each one only needs to manage the traffic actually desired by the local users, making them quite cheap to run. When federation is fully up and running, we would expect tens of thousands of these, like in the Fediverse.
Next up is the relays. I only drew two, because that seems to be the principle limitation of the architecture. You can see that every single PDS has to send every single outgoing message to every single relay. So if we start with 2 relays, and then that grows to 20, each PDS’s network bandwidth grows by 10.
Next is the labellers. This is a critically important piece of Bluesky’s story, because this is the censorship layer. Bluesky advertises “composable moderation”, meaning that anyone can set up a labeller to label “bad” content according to their own criteria. Then you as the consumer can pick and choose among those labellers to get the mix you want. This is one of the best innovations Bluesky implemented. For now, note that each labeller has to ingest the full firehose from its relay. From the relay’s side, each additional labeller imposes quite a large network load.
Then the AppView. I haven’t been able to figure out exactly what these are for. The architecture document just has a Pink Floyd album cover. I think the idea is that they work as indexers and query engines, producing tailored sub-feeds defined by their consumers. Anyway, these again ingest the full firehose from their corresponding relay. They also take a smaller (though probably still quite large) feed from each of the labellers they wish to support. They then output, presumably many, customised feeds of a manageable volume.
Finally there’s the Feed Generators. I don’t really get what these do either. But I guess this is the layer where your user account comes back into play. Your PDS is under your control, you set the settings and so forth. But from the relay through the labeller through the AppView, those are all public aggregators. You no longer control what is done with that data, and indeed the labellers may well use your data against you. The feed generator is where the public firehose turns into your own personally curated feed.
And finally that gets fed back down to the PDS. That’s how you get the replies and likes for your posts.
Traffic
I think a key problem, or consideration anyway, is network traffic.
Currently Bluesky has six million monthly active users, and apparently this generates about 30Mbps sustained traffic. I think it’s safe to say that six million is not enough to consider Bluesky a success. They were aiming to be Twitter 2.0, and they have VC funding on that basis. It’s not clear if a commercial organisation the scale of Bluesky can exist without a much larger userbase to tap for funding. So, for our success scenario, let’s imagine Bluesky has one or two hundred million monthly active users, the scale of Twitter.
I’m going to put a scaling factor on top of that. I claim that traffic scales somewhat more than linearly with the number of users, because those users spend more time each day on the app and use it more intensively. You’ll also see the ratio of likes and boosts to posts and comments rise, quick interactions suitable for consumers rather than creators. Five minutes of time liking other people’s posts produces a lot more traffic than five minutes composing your own.
30Mbps translates to about 10TB of traffic a month. Prices vary wildly, I’m going to go with $1 per TB. So currently a relay costs $10 per month in network traffic, in addition to other costs. That fits approximately what people are reporting when they talk about hosting a relay on a Raspberry Pi.
Scale up at least 20× the number of users, but each of them producing 2× as much content. Now we’re talking about $500 per month of raw network traffic, just to plug into the firehose.
Business
Hobbyists won’t pay $500 per month. Raspberry Pi relays are a transitory phenomenon, they will die out when the network scales. In my scenario, we’re in the realm of businesses. Not necessarily large businesses, and perhaps not always for-profit businesses. Nevertheless, an entity that probably has employees, and likely needs an accountant. Some of the organisations running nodes in this network won’t be for-profit businesses, and mostly these components are run in-house by full-stack organisations. However, I think it’s worth thinking about each of them as if it were a standalone business, to see where the incentives lie.
PDS
It’s cheap to run a PDS, because each of them only publishes events generated by their own users, and receives only events of specific interest to their own users. This all scales linearly with the number of users. Those users might pay a commercial fee, they might donate of their own free will, the service might be offered as a freebie by a different organisation, or a single user might be self-hosting their own server. Very much like the Fediverse.
The only thing that might go wrong is if the number of relays becomes very large, in the thousands. PDS’s must push a separate copy of every event to every one of those relays. Then, perhaps, network costs could be a problem. For reasons I’ll get to, I don’t think that will be a factor.
Relay
Relays are clearly the most demanding part of the system. Each firehose stream costs $500 per month, but each relay supports an entire ecosystem of labellers and AppViews, each of which needs its own firehose. There are no numbers, but my interpretation of the vision is that Bluesky expects hundreds of special-purpose AppViews, and thousands of opinionated labellers catering to every taste. That’s a lot.
You can’t expect relays to provide $500 per month of data for free. On the contrary, we should think of relays as being in the business of selling firehoses. Pay us, let’s say, $1000 a month, and we’ll send you our full dataset.
You might also wonder if they would charge PDS’s. But I’d say not. First of all, the volume is much smaller: the entire universe of PDS’s is by definition the same volume as only one of the firehoses the relay sells. Barely worth chasing. More than that, if the business of the relays is selling data, PDS’s are the source of that data. Really, the relay should be paying the PDS’s! In practice, there’s tens of thousands of PDS’s, and maintaining payment infrastructure either way would be a pain. So that part is just for free.
Labeller
So we can see that labellers are in a rather awkward position here. They need to pay $500 a month just for their incoming network costs, plus $1000 a month charged by the relays. How are they going to make that money back? Especially since labellers are the politically sensitive part of the puzzle. They will need to at least pretend that they are providing a public service.
This would probably look a lot like every charity: constantly begging for cash, passive-aggressively providing a service free of charge. Contrary to the dream, I don’t think very many of these will survive. Less than a hundred. But each one can label content in a myriad of ways, supporting many use cases. For example, where someone uses a transgender person’s pronouns, the labeller might register whether they use the person’s preferred pronouns, or pronouns from birth. Then trans-friendly instances can filter out transphobic content, while transphobic instances can filter out trans-friendly content. No need for two separate labellers. Let a hundred flowers bloom!
AppView
AppViews also require a full firehose. But their relationship with users is probably quite different. They are the ones at the front line providing the service. I’m not clear if the architecture requires individual users to have accounts on an AppView, but in any case it could be structured that way. You get what you pay for.
Feed Generator
Returning close to where we started, a feed generator only handles as much traffic as is explicitly requested by their users. As such, hobbyist usage is fine, and all the other business models PDS’s use.
Players
So now consider the operations of each player as an integrated entity. How are they making ends meet?
Elephant
The blue provider benefits greatly from economy of scale. Their own internal implementations, all under one roof, are relatively cheap to run. They can use these to bootstrap a service that they can then offer for money to outside users, like Amazon did with AWS. My blue provider is obviously a stand-in for Bluesky, and perhaps this is part of their business model.
Pencil Tower
The orange provider in my example is a different model – one of each, arranged in a tall narrow stack. They can save hugely on network costs because the expensive parts are colocated, with cheap networking. The hardest part is still the relay, but there are only two firehoses. Perhaps they will not achieve the economies of scale of the blue provider, but they have their own efficiencies from nimbleness and focus. An organisation like Blacksky can probably survive on donations, or by selling premium services.
Specialist
The green streaming hoster has a different model again. They are providing a specialised app, a service that the core Bluesky service cannot support at a technical level. They have fewer customers, but video streaming is hard and those customers are willing to pay for it. For the green provider, paying for a firehose is a relatively small expense, but in exchange their customers get exposure to the entire 100-million-strong userbase of the ATmosphere. It’s a no-brainer.
Charity
The purple provider is there because the blue provider is playing it safe, allowing or denying content based on what the majority likes, regardless of the damage done to minority groups. The purple provider is for people sick and tired of the mainstream commercial provider’s choices. It probably makes money from donations. Good luck with that.
Choke
My problem with the Bluesky architecture is not that it can’t function, nor that it can’t scale. It’s that it scales in a way that leaves it vulnerable to cartelisation, corporate conformity, and government intervention†. There are too many chokepoints.
The clearest example of this is the relay. Relays are big and expensive, requiring a company with investment. They benefit greatly from economies of scale. But they are also buried quite deep in the stack, only used very indirectly. Unlike, say, labellers, it’s hard for users to really identify with and support a particular relay. Users are unlikely to be aware if a relay cuts off an undesirable PDS, or be in a position to mount an effective boycott if it happens.
So relays are a prime target for acquisition and exploitation. Even if Blacksky and Northsky are running their own relays today, a successful AT ecosystem will probably see them lose control over their relays eventually, one way or another. At some point these organisations need to ask themselves, is running a relay the most important thing for us to be doing right now? In a successful but stable AT ecosystem, I would expect maybe 5 or 10 relays to exist, the majority in the USA. That’s not a lot of options.
More than just relays though, we can see that anything connected to a firehose is an organisation, not an individual. Not necessarily a giant office building, perhaps a mom and pop store. But a legal entity that is handling money, and needs licensing, registration, and reporting. It has employees, and a duty of care to those employees. Such organisations are vulnerable to bullying, whether by other organisations threatening to take them to court, or by governments. Such bullying is not limited to the government of the country in which the company is domiciled. A responsible company can’t risk its employees being arrested on their holidays, or having their offshore assets seized.
That’s not disastrous. Our entire civilisation has long been privatised. As citizens, there are ways we can stiffen the backbones of the companies we depend on. But if you’re looking for true bravery, and the ability to see beyond the profit motive, you really need individuals. You can morally put yourself in harm’s way, but not others who depend on you. And don’t look to rich individuals either. There’s a reason they’re rich.
Therefore, while I’m liberal enough to be comfortable with the profit motive keeping the whole system upright, I find it a shame that individuals cannot meaningfully make a home on the AT network without depending on for-profit companies.
Labels
This is particularly uncomfortable when it comes to labellers. Composable moderation is a genuinely good idea. But only if there is true diversity, not just in the service the labellers provide, but in the labellers’ governance. Limiting labellers to those who can start with a budget of $1.5k per month seems to rule out true representation.
I think there is a cheat-code here. Labellers don’t really need a firehose. Full context certainly is valuable – if an account mainly active in misogynist spaces suddenly posts in a feminist forum, that’s worth flagging, even if the content appears inoccuous. But you can provide a meaningful service simply by listening to explicit user reports of bad behaviour. That’s a very small amount of network traffic that can yield huge benefits for the network.
I think that requires rearranging the network slightly, in that some Labellers would now receive data from the AppView. I don’t know if that breaks anything in this architecture. However, that still leaves the AppViews as unavoidably attached to the Relay, with the Labellers dependent on them.
Bondage
Suppose we start a PDS for the BDSM community. Nothing illegal about that, and no reason for relays to block us – for now. But relays are commercial companies selling a product, meaning they are dependent on payment processors, among various other services. Time and time again we’ve seen payment processors deliberately shutting down the spicier online communities, often after some manufactured public outrage.
So after a promising start, suddenly the payment processors put pressure on relays, and relays begin blocking our site. There’s only a handful of relays, some much more systematically important than others. It would only take two or three decisions to go against us to render our community effectively cut off. They can continue to talk to each other, but members will drift away if the same platform can’t connect to their more mainstream friends.
This doesn’t even require payment processors to pull the trigger. The community would always be aware of the vulnerability, and this would have a chilling effect on what the community would tolerate. It would all be a lot more vanilla than community members would prefer.
Freedom
But there’s an alternative! Make the PDS dual-stack, so that it also communicates to the Fediverse. This would allow messages to pass back and forth between both networks, like Bridgy Fed but directly under each local community’s own control. Participants from the Fediverse and the rest of the ATmosphere could interact directly, through community posts from the BDSM PDS instance. What’s more, direct interaction would be possible with other PDS’s.
With this in place, the threat of being cut off from relays is diminished. If you are connected to friends in the BDSM community from your vanilla PDS and one day all or most relays cut you off, you can quite easily switch to a different PDS that also has a dual stack. The BDSM content will become much less discoverable perhaps, but the community is not at risk of being instantly segregated. And if the community remains united, they can find ways to gradually migrate themselves entirely to an ActivityPub-based network.
Infectious
Such a dual-stack PDS has the viral property. Suppose I meet someone at a party and it comes up that I’m on the Fediverse, they’re on Bluesky. “Let’s follow each other.” But it turns out they’re on a single-stack PDS. “Too bad. You should consider moving to a dual-stack PDS.” You know what – they might! That’s not like asking someone to move from Twitter to Mastodon. It’s the same app, the same handle, the same social graph. What’s the advantage of staying on the single-stack PDS?
Perhaps Fediverse servers should be dual-stack instead? It turns out there are several important reasons that’s a tough sell, at least for Friendica and WordPress:
- PDS’s must connect via websockets. This is an awkward fit for PHP. That might be changing, but older PHP-based applications like Friendica and WordPress would be hard to retro-fit.
- The protocol is significantly more complicated than ActivityPub, involving binary transmission formats and Merkle trees.
- Users would still need to register an account with an AppView (?)
But there’s no reason the Fediverse community couldn’t collectively fork or build a dedicated dual-stack PDS implementation. We don’t have to wait for Bluesky to do it for us.
A dual-stack PDS is a natural, almost inevitable evolution of the current landscape of federated social networking.
Goliath
Assume that the Bluesky experience really does represent what people want. Then this setup reaches a steady state. A couple hundred million users on Bluesky, a lively global community and a successful business. Around them, a thriving ecosystem of third-party alternatives, keeping Bluesky honest. Value is added, and adequate money flows through the system. The network is complex, but there are well-paid professionals there to keep it all running.
Meanwhile, the Fediverse indeed feels that Bluesky is taking all the oxygen in the room. It’s not so bad though. A million or so users is nothing to dismiss. More importantly, those users are plugged into all the dual-stack PDS’s. That’s not the whole network, but in the end there’s no good reason to choose a single-stack PDS, so most operators won’t. In the end, the Fediverse still feels like a network the scale of Bluesky. As a Friendica user watching the migration to Mastodon, I can tell you that this feels fine.
From the perspective of a Bluesky user, there’s little incentive to move to the Fediverse. The Fediverse feels slower and less connected, because it is. And there are still swathes of the ATmosphere on single-stack PDS’s that would be unreachable. But the Fediverse is a critical insurance policy. Economic or political shifts could easily knock over the teetering Bluesky towers. The Fediverse, with it’s volunteer-hobbyist ethos and trivial startup cost, is far more resilient.
Peace Out
Myself, I consider this vision, of a small Fediverse as an annex to the ATmosphere, to be pretty far from what I want. It’s much, much better than the current social media landscape. But even with the ATmosphere dominating microblogging, I think the Fediverse just works better for basically everything else, and will grow into the spaces Bluesky leaves behind.
I think the AT protocol is overengineered, fragile, and vulnerable. Of the problems it solves, only the thread-consistency problem is one that interests me. Otherwise all this effort is spent on keeping absolutely everyone in the world up to date on the very latest meme. I don’t want that.
By comparison, ActivityPub is small and nimble. If, as I believe, the AT towers are vulnerable to collapse, ActivityPub can and should be there to take over immediately when they fall. But if I’m being shortsighted in my dismissal of Bluesky’s mission, I can still benefit from their success.
† When I worry about “government intervention” here, bear in mind that I generally like government intervention, because that’s synonymous with democratic intervention, and democracy is good. But here I worry about international government intervention. There is no international democracy.