My position on ATProto, as a protocol, is that the Good Part is the PDS¹.

[mcc@mastodon.social]

My position on ATProto, as a protocol, is that the Good Part is the PDS¹. Everything good about ATProto comes from the PDS. It's the "everything else" that is the source of the problems — centralization, high barriers to entry, tendency to monopoly, some of the censorship. Unfortunately, most of the system is "everything else".

¹ "Personal data server". The repo of posts that Bluesky scrapes to form feeds.

[mcc@mastodon.social]

Now what's interesting is when you compare this to Mastodon. Mastodon has a Good Enough decentralized way of two servers talking to each other & sharing data updates. But the servers are imperfect and have forced lockin. ATProto has a Good Enough way to create a small, portable data store. But there's no decentralized way for them to talk to each other, and the awkward centralized solution creates lockin. The two solutions complement each other, if we didn't have to think about network effects!

[mcc@mastodon.social]

However we do have to think about network effects, so if we made a hybrid solution that uses a PDS to store data and ActivityPub to share the updates, I'm pretty sure we would be able to talk to neither ActivityPub nor ATProto¹. And a social network that has only you on it is pointless.

¹ Also at this point we'd probably have to actually face the fact that did:plc is a lie

[oblomov@sociale.network]

@mcc and I still fail to see what exactly ATProto offers about “small portable data stores” over the much older and not corp controlled SSB, which *does* offer ways for nodes to talk to each other directly (the equivalent of The Firehose in BS would be a large SSB relay, more or less). Heck, you can even exchange data via sneakernet.

(Of course that still ignores network effects.)