🧵 [1 / 7]

When #Bluesky says "Protocols, not platforms", they intent two things:

1. Grabbing people's attention by telling them what they want to hear.
2. Presenting the AT Protocol as an alternative to #ActivityPub to capitalize on the current hype around #Mastodon, the #Fediverse and decentralized social media in general.

The two protocols are not equal solutions for the same problem and, in fact, AT is not even a (communication) protocol to begin with.

🧵 [2 / 7]

The purpose of (communication) protocols is to standardize how two separate systems can talk to each other. They are interfaces that allow for different implementations.

ActivityPub [1] is such an interface, describing how to accept and forward content in a federated network. There are many implementations of the protocol, each serving a different application: Mastodon, Friendica, PixelFed,...

All can talk to each other and are inter-operable.

🧵 [3 / 7]

AT isn't exactly a protocol. The scope of its specification largely describes an implementation, not an interface [2] . Granted, that implementation is very flexible and allows for different applications to be build on top of it, so it may look like a protocol, but it misses the crucial part (on purpose): vendor independency.

🧵 [4 / 7]

It is not (realistically) possible to build an AT based system without relying on Bluesky code and/or their network, which puts Bluesky in the position to enforce rules and, when push comes to shove, step in to sabotage competitors that are getting too big [3] . The whole point of a standardization is to prevent exactly that.

🧵 [5 / 7]

The problem, AT (Authenticated Transfer) solves has nothing to do with federation or decentralization. It's a method for moving a user's content around in a cloud (or between clouds) and updating the storagelocation/userhandle relationship in a directory afterwards.

The purpose is to allow Bluesky to rent server capacity, on demand, from the big cloud providers and jump between their datacenters. It's simply part of their strategy of avoiding getting vendor locked-in themselves.

@raccoon this seems like a bit of a stretch to me. If Bluesky wants to be able to hop between data centers, they don't have to sell the public on a protocol, they just build the sharding internally.

I think it makes more sense to treat it as a future wish. We might lose the bet if they pivot to serving their existing customers, but the scenario you've sketched with the datacenter hopping doesn't justify straight disbelief. (To me, anyway.)

@WomanCorn

My working theory is that Bluesky wants to build a social network on the cheap. That means renting rackspace with Amazon, Microsoft or Google. So they needed sharding to avoid vendor lock-in on themselves.

Trying to sell the public on it, is exactly that: after the Twitter fiasco, the public has heard about Mastodon and federation. So now they are rebranding the sharding as federation in order to buff their sales pitch.

Follow

@raccoon People who want to do that just fork Mastodon and don't federate. (Like Gab.)

Bluesky was announced as decentralized in the first place, because Jack wanted to get out of the business of moderation.

Now they might fail at that or pivot to something profitable, but I don't think it was fake to begin with.

@WomanCorn

The two motivations do not contradict each other (and it would only be reasonable to assume that multiple motivations led to the design of AT), neither do they contradict my hypothesis that it was retrofit to align with marketing.

Sign in to participate in the conversation
Mastodon

a Schelling point for those who seek one