Gregory's ServerPart of your Bluesky identity is recorded as a DID, a kind of secure universal identifier, and to be accessible at all times, your DID has to be registered and stored on a registry. That's similar to how websites have to register their domain names with one of a handful of for-profit registries, and in fact, Bluesky handles are all domain names. So big question #1 is: Who gets to act as a DID registry? Because they will, in effect, hold the keys to your whole identity on the network.
|
14 comments
Bluesky currently has the only active PDS, and is acting as registry for all its accounts. In theory, they'll open that up to other registry providers. For anyone who already runs a website, the simplest thing would be to bundle DIDs with their current service. And maybe that's how it'll shake out—although, it's worth noting that Bluesky uses their own DID schema, rather than the one developed by the W3C. So maybe they'll end up being the central registry for all accounts on the network! Okay, so the PDS handles personal interactions, and your verifiable identity is stored on a (currently centralized) registry. What else? There's a set of account features the protocol lumps under the heading of "big world" networking, which includes "large-scale metrics" as well as algorithms and search. Those are handled by indexing services that crawl the network collecting information. Basically, Bluesky will be running its own Google for the whole network. Consent-based indexing is a hot-button issue on the fediverse, so the fact that Bluesky needs large-scale indexing to function is probably already a big red flag for many of you. But what are they indexing, exactly? Well, that "large-scale" metrics category includes likes, reposts and followers (which it would have to, in order to serve algorithms), so in effect, your entire social graph is being constantly indexed in a cloud somewhere at all times. As an aside: Expect ads. The functionality of Bluesky depends in no small part on big index servers that constantly crawl and store data about every user, regardless of what PDS they're posting from. Those index servers will almost certainly be run by for-profit companies, and they're going to want to recoup their costs somehow. They may not serve ads directly to your timeline (though, they handle the algorithms, so they surely could), but they'll serve them to you somewhere. Presumably likes, reposts and follows are also stored locally, in the data repositories for whatever PDS you're on, but for our purposes, that's entirely redundant, because they're also being indexed on these huge, centralized servers. In fact, one way to make sense of the idea that you can restore an account even when its home PDS is no longer available, is to suppose that it's being restored from an index, like pulling up a webpage archived by Google or the Wayback Machine. To be clear, I don't know if you'll actually be able to restore an account from an indexing server. The protocol doc assumes you'll do it from your CLIENT. Which means that the app you post from is expected to make a persistent backup of your entire account—"contingent on the disk space available." So if the idea of being able to port your entire post history around is a big selling point for Bluesky, expect to eventually have dozens of gigs of account data riding around on your phone. Let's assume space isn't an issue. You connect to Bluesky from your desktop computer, and its got storage enough to handle decades worth of image-and video-heavy account backups. Your account is safe, right? Maybe. To recover an account hosted by a failed PDS you'll need your recovery key, so make sure you don't lose that. And there's a 72-hour window in which it can override the signing key, so make sure none of this happens while you're taking a week-long break from social media. To summarize: Bluesky makes accounts portable by taking everything important about them off of the servers that handle posting. Identity goes to a registry. Post history goes into an ever-growing backup on your own device. And most other functions are provided by services that crawl and index the entire network. To take full advantage of account portability, then, you'll have to shoulder some of the technical burden yourself, and make a few privacy tradeoffs. The technical burdens include (but may not be limited to): making sure your DID is registered with a secure and sustainable registry that's not operated by your PDS; managing backups of your entire account history on your own devices; and keeping track of the registry key you need in order to restore an account in an emergency. The privacy tradeoff is that everything you do on the service will be indexed by third parties for use in their algorithms and (presumably) for their profit. All of this speaks to the issue of decentralization, btw. Ostensibly, Bluesky is built for federation between multiple PDS, the protocol's version of instances. AFAICT, though, PDS only communicate with one another when you @ a specific user on another server. Most of the time, they're just middlemen between your client and the indexing servers. The indexing servers are making most of the real decisions about what shows up in your timeline. Bluesky is centralized around indexers. In theory, there can be multiple indexers, and you (or, at least, your PDS) would be able to choose between them. In practice, though, it's going to be incredibly costly to run an indexer, so expect corporations and VC-backed orgs to dominate. Bluesky has the first-to-market advantage, so they'll be the big one. Twitter could well pivot to indexing on the BS protocol. Maybe a few others will pop up. That's what decentralization really means here: Your choice of corporate-run indexers.  |
In principle, you could provide your own domain, and that handle would be yours to port around as long as you continue to pay for it, like any other TLD. In practice, though, most social media users aren't going to pay for their own domain. They'll use a subdomain provided by a service. The protocol assumes that service will be independent of the PDS, but AFAIK that's not required. So maybe a PDS going offline actually COULD take a bunch of accounts with it. We'll see how it's implemented.