My position on ATProto, as a protocol, is that the Good Part is the PDS¹.
-
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.
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!
-
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!
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
-
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 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.)
-
undefined Oblomov ha condiviso questa discussione
-
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
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
-
@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.
@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. 😞
-
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 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?
-
@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?
@mcc Possibly that they're content-addressed too (though do most PDS'es use did:plc or did:web ?)
-
@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 the important thing is not that it's new it's that they built it
-
@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 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.
@mcc That's a reasonable one, to have a content-addressing retrieval endpoint!
-
@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 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 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
@mcc yeah but that's not really a compelling argument for the *protocol*
-
undefined Christine Lemmer-Webber ha condiviso questa discussione