W3C SVG

Shoot Into the Wild Bluesky

I’ve been on a journey to complete my Bluesky account setup for over a year now. The content loss I experienced as a result of the evaporation of my Infosec Twitter community in 2022 was largely mitigated by my massive (and unhealthy) Reddit diet at the time, but when they shut down 3rd party apps I knew the time had come for me to do some major social media readjustments. I started the setup of my Bluesky account back in 2023 but only barely got around to finishing setting it up today. As I re-read the docs for setting up the account I re-organized the information around the ideas of ownership in Bluesky and thought I would jot down some quick learnings on the process.

Bluesky is still pretty janky

My first prevailing observation of this process is that the Bluesky system is still in it’s infancy. It feels a lot more like a senior college project than a glabal-scale social network. There were several parts of the process that felt somewhat untrustworthy (like forcing domain ownership verification through the API when the mobile app doesn’t work) and some parts that felt more unclear than they needed to be. While Bluesky’s documentation on their federation model is still much better than it was before, there are still a lot of peices that make you wonder what the “final product” vision is for this system. For now it’s a twitter clone, but with Mastodon and activityPub gaining popularity, who knows how it will shift to compete in the future?

Owning your data != owning your name

I set up a Bluesky Personal Data Server (PDS) on the first day the code was published. I wasn’t particularly excited about the data sovereignty aspect of it, I just wanted to see how the new “federated” Bluesky worked (and I had the time to throw it up quickly). As long as your TLS and DNS are quickly tuned, the setup of this particular server is really straightforward. You can set up a new account on the server by using administrative credentials to create an invite code, then using that invite code in the mobile app to create a new user.

┌───Nov 15 14:29:18────┐
cronocide@zen:~/Desktop$▶ curl -Lv -XPOST "https://mydomain.com/xrpc/com.atproto.server.createInviteCode" \
--basic -u "admin" -H "Content-Type: application/json" -d '{"useCount": 1}'
└─Nov 15 14:29:36 •519─┘
Enter host password for user 'admin': ****************
{"code":"mydomain-com-ymy4c-lvgu5"}

However, this new account will only store data for your account, not implicitely set your handle. Your account’s default suffix is the domain of the PDS you set up the account on. So if you set up the account on mydomain.com, your data is stored on the mydomain.com PDS server, but your handle will be username.mydomain.com.

To set up example.com as your handle, you need to do several additional steps:

  • Get the DID record from the account that was registered with your PDS server, username.mydomain.com. You can do this with a call to /xrpc/com.atproto.sync.listRepos?limit=100
  • Create DNS or .well-known records for the At Protocol to use to verify your domain ownership
  • Force the PDS to change your name to the shortened root domain name mydomain.com, either through the mobile app or through the PDS CLI.
  • Restart everything just in case

Owning your name

One of the cool things about Bluesky is that it equates (or at least tries to equate) domain ownership with handle reservations. I like this a lot, as Twitter handle ownership was seen as something of an internet authority back in it’s hayday. My initial server was readily available at bluesky.cronocide.com, but I soon learned that meant my handle would be cronocide.bluesky.cronocide.com. That’s not very sexy, so I aimed to get it down to just cronoci.de.

Routing a Bluesky PDS server (in 2024) currently requires two routes to work:

  • /xrpc - This route is the root path for all PDS operations (except root domain handle changes)
  • /.well-known/atproto-did - This is needed if you want to shorten username.mydomain.com to mydomain.com

Knowing this makes the reverse proxy setup much easier. The second item there is static data: it’s a text/plain payload that includes the DID of the user account that assigned to your user when you created the account. The /xrpc routes are translated straight across to your PDS server to make the domain work. Validating your root name is supposed to use a DNS TXT record as well as the .well-known bit to verify your ownership of a domain in order to make it work. I couldn’t get either method to work in the mobile app for some reason; it kept giving me the error Unable to resolve handle. Following this post I got a CLI token from the PDS server and manually changed my name, which scarily seemed to work without saying anything:

┌────Nov 15 16:11:28────┐
cronocide@zen:~/Desktop$▶ curl -Lv -XPOST "https://mydomain.com/xrpc/com.atproto.identity.updateHandle" -H "Authorization: Bearer <token>" -H "Content-Type: application/json" -d '{"handle": "mydomain.com"}'
└──Nov 15 16:12:11 •534─┘
┌───Nov 15 16:12:13─────┐
cronocide@zen:~/Desktop$▶  ???

It’s hard to tell if the mobile and web app slowness I’m seeing are due to some misconfiguration I’ve done on my end, or if it’s just strain from the current influx of users on the network. I’m not sure how many of these users are material, since I made three or four in the process of figuring out the PDS setup alone, but then again I don’t imagine most users are going out of their way to set up a Personal Data Server for their accounts out of the gates. Either way, my PDS seems to be up and working for now. Let’s wait and see if I have to wipe my data because I chose the wrong storage class for the PDS.

Anyway, we’re off to the skies with this new social network!