I feel like I may be missing something when it comes to BlueSky, or maybe both I and those trying it out are but in different ways. My understanding is that BlueSky is currently like the Mastodon Social instance is for Mastodon but of the AT Protocol under development, with the long term aim being that once their protocol is sufficiently developed to their liking, they’ll put out the version capable of federation for others to spin up their own instances with.
However, once they do that, won’t it basically create some of the same problems people already have with ActivityPub, i.e. instance choice, federation confusion, etc.?
What’s supposed to set it apart and address existing issues rather than reinvent things and add their own distinct issues?
I believe you’ve arrived at the crux of the issue
It’s almost like federation and everything that comes with it – plusses and minuses – is the point.
At this point BlueSky had better make free liquor and hot BBQ come out of your computer if they want people to adopt it. I could be wrong, it could be real attractive, but I feel like there’s so much momentum built around ActivityPub that they’re by now fated to abandon AT for ActivityPub whether they want to or not, or else go the way of CompuServe.
Not an expert, I only have impressions …
The main difference is their architecture which is to some extent presumed by their protocol or at least designed to work with it. The architecture is more pyramidal while the fediverse is more flat/spherical. That is, ATProto will have big centralised servers receiving and sending out basically all the data, with everything else like the platform (like bsky, mastodon, lemmy) and feeds (like communities) and moderators (kinda like communities too?) processing and filtering this data stream for as it sees fit. Across these platforms, feeds etc, you’re able to move around with a single account and pick and shoes what you use. As you move further down stream from the big central server, the app you make becomes more simple to make (like the feeds in BlueSky now).
The idea being that individual instances aren’t so central to the system, which I think is a good thing. Users are more free in their system to move around without new accounts and losing or breaking the connections they’ve made. Also makes sense to me.
The big alarming aspect is the primacy of the big central server. They’ve said that multiple can exist but that it’ll be like search engines, only a few will bother to put in the effort.
By comparison, the fediverse is flat … a bunch of independent instances communicating with each other as they see fit. That’s basically it. Each user is bound to and stuck on their instance, which means when defederation happens it can be quite dramatic for the simple and obvious reason that all the users of an instance aren’t the same or hold the same values.
Frankly, it’s a system designed to create drama, while, IMO, mostly failing at its purported purpose, which is to foster communities. Because, first, you need software platforms to facilitate, and most on the fediverse suck at it (where are instances specific private chat rooms of any sort on the fediverse), and second, communities grow organically which is actually impeded by being stuck on an instance.
The latter is why we have federation in the first place … organic community building … which apart from basic moderation needs really calls into question whether the whole instances thing has much value apart from being the obvious Web 2.0 circa 2012 way of doing decentralisation. Taking the tight coupling between user, instance, platform, moderation (and allegedly community) but instead allowing these to be modular and composable with the user in the driving seat all sound like good ideas to me.
I personally hope ATProto mostly delivers on the promises of their system so that this whole idea of a decentralised social internet can move forward.
I actually set out to answer this question in a blog post, but it turns out that the answer is quite complicated, so I have to write an entire series about it. First part I published this week, which explains all the different components that make up the Bluesky network:
https://fediversereport.com/how-bluesky-works-the-network-components/
I don’t think that they’ll run into the exact same problems that AP-fedi has, as the design decisions are often made specifically to avoid some of these. However, their design decisions create new sets of problems for the network, which I’ll get into later
A friend was asking about reading materials for the fediverse, specifically around how different platforms are handling instance selection. I’m taking a look through your past blog posts, but would you have any links handy for me to pass along?
