Bluesky is down today. "Hah", I think, "since I use a self-hosted PDS for posting and Blacksky for viewing posts, I can go on using the service just fine".

Blacksky can't show me my own posts. I can make them and they show up on my PDS, but my profile shows none more recent than last night.

I wonder if Blacksky is coincidentally having server problems, or if Blacksky has a still-undisclosed dependency on Bluesky services. (It *does* have disclosed use of Bluesky moderation; maybe that's it.)

There's a bit in Terry Jones' "Starship Titanic" where an alien gets caught in a traffic jam on Earth, and explodes "your transportation system is so poorly designed! when more people use it, it goes *slower*! you should design it so it goes *faster*— to accommodate the extra load!".

It's funny because the former seems like the obvious, natural way transportation works, and the latter seems to require magic alien future technology.

P2P is a world where naturally the more people use it, the faster and more resilient the network becomes. Load gets distributed. Working nodes talk to each other and ignore nonworking nodes. That's how the primitive, BitTorrent era systems worked.

Bluesky somehow applied superfancy alien future technology to invent P2P traffic jams. When one node goes down, the others go down because they depended on it. Because it's a mesh of interoperating microservices by different providers, not federation.

This appears to be the explanation:

https://blacksky.community/profile/did:plc:w4xbfzo7kqfes5zb7r6qv3rw/post/3mjmztqnuwc2g

In Bluesky, the PDS talks to the relay talks to the appview talks to the client. Blacksky set up all four last year. But they only deployed their PDS and client, at first. They used Bluesky's relay and appview. This wasn't clearly disclosed. Then there was a censorship scare, and they switched to their own appview. But apparently they're still using Bluesky's relay. This wasn't clearly disclosed. Now relay death can screw Blacksky.

Now, interestingly, this means that Blacksky users can continue talking to Blacksky users. I can read Rudy's posts on Blacksky. Because that bypasses the relay. But¹ to read my *own* posts, *on a self-hosted PDS*, Bluesky is apparently required, because Blacksky relies on Bluesky's "relay" to scrape my PDS before it gets added to the Blacksky appview database.

¹ (if I'm interpreting Rudy's posts correctly, hardly a guarantee)

And it's extremely relatable why Rudy took this shortcut of "build out our own stuff, but rely on Bluesky's components until we're forced to drop it": *Because standing up your own Bluesky stack is nightmarish!* It is a borderline miracle that a team his size made this work at all; I'm not sure a third team could replicate to the extent Blacksky has (and even on non-outage days, there are still large technical problems with Blacksky which cannot conveniently be fit in this thread).

Because this is the other "we used future alien technology to make it worse" thing about Bluesky.

In the "natural", Hobbesian form of P2P, the more nodes you add the less work per node you need to do, because of work sharing.

But Bluesky's "federation" is like blockchain. When you create a second "instance", that instance must duplicate *literally all the work* of the first instance. It must scrape all the posts itself. It must archive all the posts itself. It must CSAM-scan the posts itself.

This is why I believe Bluesky was never meant to be federated. To create a Bluesky "instance", like Blacksky is heroically attempting, you have to perfectly duplicate every server Bluesky runs. But Bluesky is a business operating at a loss by burning unlimited-for-now VC cash. That has always implied only a business with unlimited VC cash can create an instance. Blacksky is succeeding. Except on days where they aren't.

TLDR

1. My definition of "P2P" or "Federated" is that if server A goes down, servers B and C can still talk to each other.

2. Bluesky/"Atmosphere" fails at this because Blacksky (B) utilizes Bluesky (A) to talk to me (C).

3. In order for Blacksky to avert this, they have to do something unreasonable and expensive.

4. Blacksky someday *will* do this, but will depend heavily on massively overworking Rudy and a few other people. This may someday fail.

5. ActivityPub has problems, but not these

(And *how* does ActivityPub avert these problems? Well, ActivityPub has the "instance" abstraction. The federate-or-defederate relationships serve as a basic web of trust so some work, like moderation, doesn't have to be fully duplicated. Data is shared between instances only when a follow-relationship requires it, reducing work. Instances can still get too big and maintainers overworked, but you can fix that problem with more, smaller instances. As above, *there ARE no small Bluesky instances*)

@mcc in fairness, I don’t think they ever pretended that federation was a goal, their main claim was the protocol prevented user lock in by providing a credible exit (“if we become evil, some other big player can create their own appview and steal our users”)

@galactus okay well, i want to have a system where i can escape from the clutches of big player A without needing big player B to need to help me.

why should i trust big player B more than big player A, after all? they're big, so probably eventually they'll act the same way.

@mcc I agree, but I think it is honest to acknowledge that having big indices of the whole network is nice, and we don't yet know how to do that without the kind of $$$ that only big players have.

@galactus @mcc i am super confused by this stance, for the internet at large imagine if every server needed to keep a backup copy of the entire internet? sure that would definitely be the most resilient possible internet but who could actually afford that? the whole point of the new wave of federation / decentralization was smol = better and bsky outages just prove that.

@galactus @mcc i am aware of atproto designs that can handle not the whole firehose but as i watch the brilliant people working on this i am reminded of people squeezing blood from a stone. the original design is as you said big indice or as some others have said big heap .. it just seems top heavy and expensive for normal ass internet weirdos to be able to run?

@fleeky @mcc Sure, but that's kind of my original point, no? They're not claiming everyone can or should run a full index. They're saying the architecture makes it possible for others to do so, and that this is decentralized ("credible exit") enough and delivers better (arguably) UX (discoverability, consistent timelines, etc, with decent latency).

Again, this isn’t necessarily my view, I'm just trying to represent their philosophy as accurately as I can.

@galactus @mcc i also feel the need to constantly point out the genesis of atproto , pfrazee was working on dat/hypercore/beaker browser .. he had to throw his hands up and say decentralization doesn't work in any practical sense (its hard for sure) he was then broke and got a job at bluesky to essentially port ctzn (his live coded social media experiment) to bsky ,, he basically took ideas that were maybe 3/4's of the way done and thats what we have now.

@fleeky @galactus i would rather have used beakerbrowser :(