This is one of the better criticisms of bsky/atproto I’ve read. So glad to read a good one. Just two comments:
DMs were added out of protocol for exactly the reason the author suspects: users were clamoring for this functionality, and doing it right will take a while. So they’ve alluded to plans to bring them back into the protocol, but for now, most people are okay with trusting Bluesky and being able to do what they want to do. It’s effectively a non-regression from the point of “I’m migrating from Twitter.”
> it seems unlikely that downplaying the role of domains is something Bluesky as an organization will be motivated to do since selling domains is currently a Bluesky business strategy.
It seems like this integration has disappeared, as far as I can tell. They didn’t say anything about it publicly that I saw.
To offer a different perspective, I think this is lazy criticism. There is a fundamental tradeoff between the "sharding strategy" of a social network and user experience. Both bluesky and mastodon are reasonably pareto-optimal given this tradeoff.
Mastodon goes for real "decentralization" with tiny shards of the "content tier", which means:
1. There is a lot of intra-shard bandwidth but relatively limited inter-shard bandwidth. You can create a truly seamless global experience, with global search, recommendations etc.
2. There is no uniformity in user experience (say moderation-wise) as each shard is essentially a personal fiefdom.
Bluesky instead decouples the storage layer from the caching + serving layer. This allows data portability but still allows a truly unified view of the social network.
Users are free to choose between the two approaches and most overwhelmingly choose Bluesky. But it is not very thoughtful to criticize a pareto-optimal design point for compromising one property to gain another.
"I think this criticism is good" does not mean I agree with it; it's just that I have read so many criticisms that are poorly formed, come from a place of ignorance, stuff like that. This one is at least informed, doesn't make any obviously factually incorrect statements, seems to be trying to provide more heat than light, etc.
There have only ever been 3 models: NNTP, email, and IRC. ActivityPub is email, that is different servers have different data. Bluesky is NNTP, that is different servers have the same data.
I think a lot of this work is cool, in particular I love the stuff cribbed from IPFS. But I think the main idea here ("we got into trouble because we took responsibility for moderation, let's at least make it possible for it to be someone else's responsibility so we can say 'hey, you might not like our moderation and that's fair; just run your own!'") doesn't address the core problems Twitter had. This structure of media heavily incentivizes shallow communication and rage bait. It divides us by reducing us to cardboard cutouts of our hottest takes and worst moments. It isn't a good idea. Making it impervious to Congressional scorn isn't a step in the right direction.
But OK, stipulating I'm wrong here, it seems fully bonkers that in order to "decentralize" a platform like Twitter that each node has to have a full archive of everything. Who realistically would do this? Wouldn't it be easier to offer your own moderation algorithm or client instead? Is it supposed to protect against Elon Musk buying it too? Feels like being open source and running some replicas is easier (again, the NNTP model).
Both are worth reading. So much analysis starts with either doubting the intentions of the Bluesky people or from some level of misinformation or misunderstanding, and it's hard to even begin addressing that.
Informed critique is vital to keeping things on track. This sets the standard.
This is also written by one of the person who helped create ActivityPub and worked along Jay Grabber to create one of the first proposals at twitter for the thing that eventually became the ATProto.
Jay collaborated on multiple distinct proposals prior to Bluesky PBC, back when it was a community effort. I wouldn't suggest a lineage from that proposal and atproto.
> Bluesky uses content-addressed content, so that content can survive if a node goes down
Does anyone have recommended reading about how Bluesky implements this? I've skimmed the docs at atproto.com but I'm not sure how this fits in there. It's also not clear to me how content-addressed content protects against node failures in general.
> It's also not clear to me how content-addressed content protects against node failures in general.
Imagine my PDS host disappears. Server's gone.
I can spin up a new PDS of my own, or sign up for one that exists, and then replay all of my posts from the relay, and put them into the new PDS. I'm now back up and running without any involvement from the old PDS host.
Does the relay durably store data from the PDSes it crawls? I thought it just aggregates and distributes data from the PDSes it is actively connected to.
Edit: I now see via https://docs.bsky.app/docs/advanced-guides/backfill that this is the case. I'm surprised that the docs don't mention it more clearly that relays store the full contents of the attached PDSes, but maybe I'm just not up to speed on learning how this works.
Currently the relay stores the entire history. That’s why people are saying that it’s a centralization point that’s unlikely to be able to be hosted by others as the network grows.
That said the team is aware of this and has ideas for how more limited subsets could work. That’s more important as time goes on, so this is yet another one of those prioritization related issues where improvements will happen, but it’s also good to know about the current state of things too.
This is one of the better criticisms of bsky/atproto I’ve read. So glad to read a good one. Just two comments:
DMs were added out of protocol for exactly the reason the author suspects: users were clamoring for this functionality, and doing it right will take a while. So they’ve alluded to plans to bring them back into the protocol, but for now, most people are okay with trusting Bluesky and being able to do what they want to do. It’s effectively a non-regression from the point of “I’m migrating from Twitter.”
> it seems unlikely that downplaying the role of domains is something Bluesky as an organization will be motivated to do since selling domains is currently a Bluesky business strategy.
It seems like this integration has disappeared, as far as I can tell. They didn’t say anything about it publicly that I saw.
To offer a different perspective, I think this is lazy criticism. There is a fundamental tradeoff between the "sharding strategy" of a social network and user experience. Both bluesky and mastodon are reasonably pareto-optimal given this tradeoff.
Mastodon goes for real "decentralization" with tiny shards of the "content tier", which means:
1. There is a lot of intra-shard bandwidth but relatively limited inter-shard bandwidth. You can create a truly seamless global experience, with global search, recommendations etc.
2. There is no uniformity in user experience (say moderation-wise) as each shard is essentially a personal fiefdom.
Bluesky instead decouples the storage layer from the caching + serving layer. This allows data portability but still allows a truly unified view of the social network.
Users are free to choose between the two approaches and most overwhelmingly choose Bluesky. But it is not very thoughtful to criticize a pareto-optimal design point for compromising one property to gain another.
"I think this criticism is good" does not mean I agree with it; it's just that I have read so many criticisms that are poorly formed, come from a place of ignorance, stuff like that. This one is at least informed, doesn't make any obviously factually incorrect statements, seems to be trying to provide more heat than light, etc.
There have only ever been 3 models: NNTP, email, and IRC. ActivityPub is email, that is different servers have different data. Bluesky is NNTP, that is different servers have the same data.
I think a lot of this work is cool, in particular I love the stuff cribbed from IPFS. But I think the main idea here ("we got into trouble because we took responsibility for moderation, let's at least make it possible for it to be someone else's responsibility so we can say 'hey, you might not like our moderation and that's fair; just run your own!'") doesn't address the core problems Twitter had. This structure of media heavily incentivizes shallow communication and rage bait. It divides us by reducing us to cardboard cutouts of our hottest takes and worst moments. It isn't a good idea. Making it impervious to Congressional scorn isn't a step in the right direction.
But OK, stipulating I'm wrong here, it seems fully bonkers that in order to "decentralize" a platform like Twitter that each node has to have a full archive of everything. Who realistically would do this? Wouldn't it be easier to offer your own moderation algorithm or client instead? Is it supposed to protect against Elon Musk buying it too? Feels like being open source and running some replicas is easier (again, the NNTP model).
To save one the trouble of chasing one of the dead links from their co-submission snippet <https://gitlab.com/-/snippets/2535398>: https://web.archive.org/web/20221206075054/https://agoric.co...
There's an in-progress thread version with discussion: https://social.coop/@cwebber/113527462572885698
Both are worth reading. So much analysis starts with either doubting the intentions of the Bluesky people or from some level of misinformation or misunderstanding, and it's hard to even begin addressing that.
Informed critique is vital to keeping things on track. This sets the standard.
This is also written by one of the person who helped create ActivityPub and worked along Jay Grabber to create one of the first proposals at twitter for the thing that eventually became the ATProto.
Jay collaborated on multiple distinct proposals prior to Bluesky PBC, back when it was a community effort. I wouldn't suggest a lineage from that proposal and atproto.
I only wish this website would be adapting to the viewport width. It's good awful to look at on mobile
I was just about to close it but readermode worked Safari iOS
> Bluesky uses content-addressed content, so that content can survive if a node goes down
Does anyone have recommended reading about how Bluesky implements this? I've skimmed the docs at atproto.com but I'm not sure how this fits in there. It's also not clear to me how content-addressed content protects against node failures in general.
Through stuff like https://ipld.io/specs/transport/car/carv1/
> It's also not clear to me how content-addressed content protects against node failures in general.
Imagine my PDS host disappears. Server's gone.
I can spin up a new PDS of my own, or sign up for one that exists, and then replay all of my posts from the relay, and put them into the new PDS. I'm now back up and running without any involvement from the old PDS host.
Does the relay durably store data from the PDSes it crawls? I thought it just aggregates and distributes data from the PDSes it is actively connected to.
Edit: I now see via https://docs.bsky.app/docs/advanced-guides/backfill that this is the case. I'm surprised that the docs don't mention it more clearly that relays store the full contents of the attached PDSes, but maybe I'm just not up to speed on learning how this works.
Currently the relay stores the entire history. That’s why people are saying that it’s a centralization point that’s unlikely to be able to be hosted by others as the network grows.
That said the team is aware of this and has ideas for how more limited subsets could work. That’s more important as time goes on, so this is yet another one of those prioritization related issues where improvements will happen, but it’s also good to know about the current state of things too.