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.

[moira@mastodon.murkworks.net]

@mcc Exactly. If you listened to them talking about it early on - particularly about the relay situation - they were clearly modelling along the "four or five competitors, like broadcast TV networks" system.

Relays are intrinsically expensive, and bans are _broad_. The model sacrifices granularity of defederation and the most important (to my mind) advancement of ActivityPub and Federation: using the Nazi bar phenomenon _against Nazis_.

The Fediverse is the first and thus far only approach to pull that off and the importance of that innovation should not be minimised.

[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.)

[mcc@mastodon.social]

Question: "how infeasible/impossible is a hybrid server that satisfies both protocols [AtProto PDS and ActivityPub] simultaneously?" https://xoxo.zone/@clarity/115306161120635648https://xoxo.zone/@clarity/115306161120635648

Answer: M. Kasprzak already did this, in June of this year https://bsky.app/profile/did:plc:svpym4ujks7qxczscyzq7fuy/post/3lr5iki7sf22a

[mousey@mastodon.seattlematrix.org]

@moira @mcc This. Explaining that the fediverse is Billionaire-proof, because when they show up trying to colonize the network, the Fediversal community can simply kick them out without affecting the greater community. There's even degrees to which they can be ostracized.

This makes the lightbulb appear in people's eyes when I'm explaining the Fediverse to people just hearing about it, but that lock those commercial solos have on people's brains just seems so insurmountable. 😞

[cwebber@social.coop]

@mcc But really, is there anything that's "new" to PDS'es that isn't basically a blog + RSS/atom feed? Signed posts seems like the main one?

[cwebber@social.coop]

@mcc Possibly that they're content-addressed too (though do most PDS'es use did:plc or did:web ?)

[mcc@mastodon.social]

@cwebber the important thing is not that it's new it's that they built it

[mcc@mastodon.social]

@cwebber also the thing I see the PDS as providing at root is "a standard API for requesting data objects by key". a blog isn't that, you can address it by key (URL) but it returns formatted HTML not a data representation. RSS isn't that either, RSS is a linear recency-biased stream, and anyway we don't want RSS we want ActivityPub. You could expose the PDS xrpcs from Wordpress with a plugin the same way you can add ActivityPub to WordPress with a plugin.

[cwebber@social.coop]

@mcc That's a reasonable one, to have a content-addressing retrieval endpoint!

[mcc@mastodon.social]

@cwebber But also, WordPress is a horrible, security-vulnerability-infested nightmare to maintain, and the BlueSky PDS is easy and resource-cheap to maintain, so I'd rather have (and eventually, will write) PDS with a wordpress-like frontend than WordPress with a PDS-like frontend

[cwebber@social.coop]

@mcc yeah but that's not really a compelling argument for the *protocol*

[trwnh@mastodon.social]

@mcc @cwebber arguably the concept of storing data is not new, no -- although you do get some benefits from the merkle tree stuff

imo the real value is in lexicons as a way to coordinate conventions. a lot of this boils down to "reverse dns namespace" but there is a very well-known problem in e.g. solid where everyone can interface with the storage pods (~pds) but no one knows how to agree on where things should be stored. example: do you store birthdays in your contact book or your calendar?

[mcc@mastodon.social]

@trwnh @cwebber however also
- i think some previous systems, like protobuf, did this already, and
- at the same time they introduce the concept of the "lexicon" they poison it, by using the "schema" to absolutely, positively, in any bluesky-derived system, ban microblog posts with more than 300 characters. so the lexicon is good but you don't want to use it or you are limited to 300 characters

EDIT: typed the wrong word. the first time.

[trwnh@mastodon.social]

@mcc @cwebber that's a problem with the schema being 1) too strict, 2) entirely vertically controlled by bsky as an "app" vertical

a looser schema based on consensus standards instead of apps would probably be better in the long term

[trwnh@mastodon.social]

@mcc the web has 5 billion users and i'm the only one on my website. we really ought to be looking at how to establish identity, auth, etc cross-site on the web instead of tying it all up into platforms...

[mcc@mastodon.social]

@trwnh Yeah. Hence the power of DID. Except that we've sorta poisoned DID now by introducing a half-solution, did:plc, which is fundamentally unacceptable but which is better to do better than from an end-user perspective.

The thing that upsets me about bluesky is it's not a very good solution but it is situated in the market in a way that makes it socially difficult to introduce better solutions.

[trwnh@mastodon.social]

@mcc one thing that bothered me about that "open social" article that was going around earlier is that it dismisses personal websites as somehow not supporting aggregation, which is ridiculous because there are multiple ways to aggregate data from websites

i really think you could do a lot of this stuff on websites with existing tech, you just need to be able to negotiate identity and access control. like imagine just using HTTP (WWW-Authenticate header, *fully* define an auth scheme...) for it