So, if you’re online poisoned like me, you may have noticed that Bluesky CEO Jay Graber has been having sort of a slow motion, low-key public meltdown for the past several weeks. Most recently, in this interaction with a user.
[…]
Even with practical technical decentralization, the vast majority of Bluesky users are on, well, Bluesky. Bluesky was never really packaged as something that was relatively easy for someone to spin up on their own servers; the network has been historically extremely centralized, and only small minorities of users have broken off.AT Proto decentralization doesn’t exist as a practical reality, and if it ever does it won’t be for years. Most of the work driving effective decentralization is being done by third parties, who have limited guarantees about future compatibility with possible breaking changes on Bluesky’s end.
Bluesky inc isn’t really making ‘a protocol’, they’re making Bluesky, the monolithic (to within a rounding error) social network that they operate.
I do genuinely believe that the Bluesky team set off from the start to create a decentralized protocol, but unfortunately for them they ended up running a social network. And at this point, AT Proto has become essentially a sort of ideological vaporware; a way for Jay Graber et al to run a social media platform while claiming they don’t run a social media platform.
This is, of course, just another iteration of the Silicon Valley monoproduct: power without accountability. The tech industry elite are very much like Gilded Age railroad barons – buying up whole towns, breaking up strikes, imposing top-down economic policy on whole sectors – except all the while they claim that they are just technology enthusiasts playing with their little trains.
This depends on what you think the purpose of ActivityPub is and subsequently the type of scale. ActivityPub is designed for horizontal scale in a “social network”. If you have lots of participating entities with a more or less similar number of interconnected subscriptions ActivityPub scales extremely well, unlike ATProto, which needs to more or less ingest the entire network in its firehose.
But you are right that ATProto is better designed for “social media”, meaning that most subscriptions are one sided affairs with highly visible “influencers” being the main point around which the network operates. Obviously this is what most commercial networks are more interested in as it allows profitable advertisement and other forms of social influence.
I see these two types as entirely different forms of social interaction, and couldn’t care less about the latter. So I am not worried at all about scaling issues of ActivityPub, as it scales extremely well in the “social network” type of interaction.
I like this take, but I wonder if there’s eventually a combinatoric problem with having hundreds of thousands of small instances, each with thousands of connection to other instances? I have no idea how that relates to the network/computational constraints…
Modern webservers don’t have a problem serving thousands of requests as long as they are spaced out a bit timewise. And since each AP instance only sees and interacts with a small part of the overall network it should not become an issue to expand the network horizontally. It is anyways probably better to think of interconected archipelagos and not of a singular network in the case of ActivityPub.
Is that really true though? Say we end up with 10k servers with 100-1000 users each, even if only 10% of those users have a connection to a server that no one rose on their server is connected to, that’s still a highly connected network.
Then add boosts from other servers (that incentivise cross-network follows)…
Mastodon already has those numbers you mention and there are no performance issues in the overall network.