My position on ATProto, as a protocol, is that the Good Part is the PDS¹.
Senza categoria
27
Post
7
Autori
0
Visualizzazioni
-
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.
-
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 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.
-
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*
-
@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?
-
undefined Christine Lemmer-Webber ha condiviso questa discussione
-
@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?
@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 charactersEDIT: typed the wrong word. the first time.
-
@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 charactersEDIT: typed the wrong word. the first time.
-
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
@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 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...
@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 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.
@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
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Buona giornata mondiale della #nonviolenza!
-
@Alberto 😁
-
Milano mia ❤️
#freepalestine
-
Ora la smetto di leggere la TL prima che abbia una combustione spontanea
-
@aeva so like doing this?
https://jroweboy.github.io/c/asm/2015/01/26/when-is-main-not-a-function.html
-
@vkc it's a shame the fediverse wasn't really ready when Xitter Xit the bed and everybody worth following made for the door. All the funny/weird Twitter folks ended up on Bluesky, and I guess we'll have to wait for it to get really bad in the manner of Twitter, maybe one of the other technofascist billionaires will acquire it, I don't know. Probably won't be any time soon.
But, they've made it clear several times they're moderating like a business and not like a community.
-
@PaoloParti
Hai avuto più cool di me! 😂👍
-
Once again, I don’t change my display to be Halloween-themed because a fire demon is about as on-brand as you can get there
(And also because I would probably forget to change it back for at least several months)
