As Bluesky begins to open up more and more, it’s felt more pertinent to try to wrap my head around it. To help in this, I decided to write out my rough understanding of it from its documentation, in the hopes that it may help others and myself with any corrections from misunderstandings.
As Bluesky themselves note, the architecture is laid out in Personal Data Servers, Relays, & App Views. The intent is that each of these may be deployed and/or developed independently of Bluesky, with some caveats to each.
First & foremost, which is somewhat glossed over, is the notion that ordinary people will have the knowledge or interest in deploying their own Personal Data Servers. This isn’t really touched on from what I’ve seen in their documentation, despite it being touted as such a major benefit of the architecture.
Second, which is recognized in their documentation, is that due to the high volumes of data involved, there are likely to be fewer Relays deployed instead of many. See the following:
The federation architecture allows anyone to host a Relay, though it’s a fairly resource-demanding service. In all likelihood, there may be a few large full-network providers, and then a long tail of partial-network providers. Small bespoke Relays could also service tightly or well-defined slices of the network, like a specific new application or a small community.
This inarguably undercuts much of the benefit of it as a distributed network given that Relays are what may enable much of the transfer of data across the network.
It is noted that this may be avoided via server-to-server networking, so we’ll have to see how that shakes out given it’s mentioned almost as an afterthought.
Third, data portability across a distributed network is absolutely an achievement, but it must be scrutinized. Their language concerning PDSs itself indicates they expect them to be as prone to ephemerality as existing fediverse instances, see:
We assume that a Personal Data Server may fail at any time, either by going offline in its entirety, or by ceasing service for specific users.
Data portability then is reliant on a few crucial details:
Clear communication of the need to safely store recovery keys and backups.
Retention of recovery keys in some way (people never lose recovery keys, right?).
Device safety/stability to ensure access to your Authenticated Transfer client’s backed up data, and sufficient storage for said backup.
From that last section note the following about PDSs, “…or by ceasing service for specific users”, and then see their documentation on PDS Entryways.
Bluesky runs many PDSs. Each PDS runs as a completely separate service in the network with its own identity. They federate with the rest of the network in the exact same manner that a non-Bluesky PDS would.
[…]
To enable this, we introduced a PDS Entryway service. This service is used to orchestrate account management across Bluesky PDSs and to provide an interface for interacting with bsky.social accounts.
What’s noteworthy here is that in creating Bluesky Social, they’ve essentially created a model that I foresee others building on the AuthTransfer protocol emulating. Many everyday people won’t be spinning up their own PDSs, in the same way that few people spin up their own fediverse instances. Essentially instead of PDS Entryways, what may emerge may be AuthTransfer Entryways/Gateways for whatever variety of apps may eventually be built on it.
Similar to different fediverse platforms, you may then eventually see AuthTransfer platforms that pair together Entryway services with an App View as Bluesky itself is presently doing. Arguably this may make the AuthTransfer network no more decentralized (they go back & forth on describing their approach as decentralized and distributed) than the ActivityPub network is.
Lastly, regarding custom feeds and composable moderation, there is something on a protocol level here that those using ActivityPub may look to and improve on (and may already be doing so).
In some cruder ways, however, these are already in play on the fediverse. Custom feeds exist here on Lemmy via different communities and instances. More topic-focused instances (on Lemmy as well as other fediverse platforms) in particular can collaboratively produce distinct local and federated/all feeds. To a limited degree similar may be said of “composable moderation” with community moderation and user/instance blocking.
Mastodon even permits the sharing of one’s mute/block lists, albeit admittedly somewhat clunkily.
Altogether the AuthTransfer protocol definitely makes some interesting improvements, but not without some awkward tradeoffs that they seem to be trying to talk around instead of speaking more plainly about.
Addendum, as I wasn’t sure if I was about to hit a character limit:
The idea of regular people spinning up a Personal Data Server is already pretty laughable, but it’s accentuated by the idea that they might also go out of their way to pay for a domain name to sort of establish(?) their identity across the AuthTransfer network. Many will likely simply have names like around here as @name.atentryservice.tld.
Also there’s a kind of weird disconnect throughout the documentation from the idea of people perhaps wanting to operate multiple handles/identities for different platforms, or different purposes on the same platforms. A lot of thought seems put into owning/maintaining a singular identity, but not as much to multiple identities.
You must log in or register to comment.
Thanks for the digest. The PDS concept tangentially helped me (maybe?) better understand the ideas behind Solid ActivityPods as personal data stores for ActivityPub.
Bluesky feels like there is still too much data silo mentality behind the project, and the federation part seems more like a symbolic gesture than something that is meant to actually allow users their data freedoms? Call me cynical.
Bluesky feels like there is still too much data silo mentality behind the project, and the federation part seems more like a symbolic gesture than something that is meant to actually allow users their data freedoms?
I keep going back & forth on this tbh. I don’t think it’s merely symbolic, but I think it makes the same kind of mistake many tech-oriented people make in imagining that many people will know how or even want to run their own servers.
This is why towards the end I mention that I foresee the AuthTransfer protocol producing more or less similar platforms to the fediverse despite the differences in architecture. Supposing Bluesky continues apace with the release of their work, we may see something like an atproto.xyz that’s basically an independent microblogging service like Bluesky but with whatever custom adjustments they’ve made. The whole PDS idea will fade into the background as this independent service emulates the Bsky Social model of acting as a PDS entryway service and platform.
Any decentralized benefits many were intended to find via AuthTransfer’s PDSs will sort of end up falling to the wayside, which may be okay if you’re okay with that. At that point it’s just another distributed model though, and should be assessed on those grounds for whatever benefits or downsides it possesses compared to others.
ack. it just seems like so much control is retained by those big relays/entities.
the single benefit to end users (that end users are aware of) is the data portability… but if its not portable out of the box, ie, no domain name required, those people are gunna freak.
whole endeavor (blueksy using AT) smells like suuuuuunk cost fallacy
Fwiw as I understand it data portability is possible without a custom domain, aside from your handle/name. A custom domain only seems necessary if you want to prove and maintain your identity across AuthTransfer services/platforms that permit/enable custom domains in handles. It’s basically a more direct form of the website verification one may find on federated platforms like Mastodon.
Without it you’d be jumping between subdomains and top-level domains in your username/handle similar to how you do so on ActivityPub platforms, i.e. @uniquename.bsky.social -> @uniquename.otherATprotoplatform.tld.
Great writeup! A couple thoughts:
First & foremost, which is somewhat glossed over, is the notion that ordinary people will have the knowledge or interest in deploying their own Personal Data Servers. This isn’t really touched on from what I’ve seen in their documentation, despite it being touted as such a major benefit of the architecture.
Very true. There’s a line buried in their white paper that “we expect that most users will sign up for an account on a shared PDS run by a professional hosting provider – either Bluesky Social PBC, or another company” but they very much do tout it as a major benefit. It’s certainly true that the ability to move your data around is a very good thing, and something the fediverse is bad at today, so from a positioning perspective it makes sense to focus on this; their claims that this gives the user power are, um, exaggerated.
due to the high volumes of data involved, there are likely to be fewer Relays deployed instead of many.
Yeah I was in in a discussion where a Bluesky developer suggested that non-profits might run their own Relays … seems unlikely to me, both because of the volume and because of the risk of potentially relaying content that’s legal in whatever jurisdiction the PDS is in but not in the Relay’s jurisdication. Of course Relays don’t have to be for the full network, so we might see more smaller-scoped Relays (although I’m not sure how that differs from a Feed Generator), but if BlueSky and a few others provide the only full-network Relay, that’s a pretty powerful position for them to be in.
Also in that conversation the said that AppViews are likely to be even more resource-intensive than Relays, and so anybody developing an AppView might as well have a Relay as well, so there’s likely to be the same kind of power concentration.
That said I think it’s very good that Relays explicitly appear in their architecture. Relays are also critical for smaller or less-connected instances in today’s fediverse, but don’t get a lot of attention.
Arguably this may make the AuthTransfer network no more decentralized (they go back & forth on describing their approach as decentralized and distributed) than the ActivityPub network is.
Yep. They’ve split the functions of the ActivityPub instance, but it seems to me that they’ve just shifted the power imbalances around, and potentially magnified them.
