parker higgins

Bluesky, AT Protocol, and the exciting possibilities of URLs as usernames

I’ve been posting for a few weeks now on bluesky, a new social network built on new technology called the AT Protocol. Everything about that stack—the app, the network, the protocol, etc—is under active development and subject to change (and my understanding might not be fully correct), but I am excited about one component in particular that I think is still underappreciated.

Namely, it’s the protocol’s first-class support for domain names as handles. This design decision may not seem as radical as it is, because for now there is only one star in the bluesky constellation. But if the network continues to grow, this role for domain names could have pretty major implications.

My domain is my passport, verify me

Even today, there are a few big consequences. The first comes as a result of the fact that a domain username requires demonstrating control over the domain itself (through the use of a DNS record). In light of the blue-check verification tire fire happening at Twitter, a lot of focus has been on the way domains-as-usernames delegate out the verification function: bluesky employees don’t need to confirm by hand that the accounts purporting to be the Washington Post or Senator Ron Wyden are who they say they are, because in both cases they have verified through DNS records.¹ Washington Post’s username is @washingtonpost.com, and Wyden’s is @wyden.senate.gov.

Situating the question of identity verification at the DNS level makes a lot of sense to me. Much of our security models of the web already rely on the domain name system being sort of an ultimate source of truth; consider how much anti-phishing advice boils down to “manually enter the domain in question to get you back to safe territory.” In the case of Senator Wyden, even the top level .gov domain is an indicator of (some level of) trustworthiness.

Here and elsewhere, I think it is useful to compare with the approach that Mastodon² has taken. Some people have rigged up small Mastodon instances at domains they control to allow them to effectively confirm their identity through their username, but for the most part verification happens by demonstrating control not of the DNS responses for a URL, but instead over the content served from that address. My Mastodon profile has a verified link to parkerhiggins.net because of the rel="me" link at the top of this page.

There are pros and cons to each of these approaches. I think the Mastodon approach is most reasonable in a world where people run servers that serve blogs or personal home pages or project portfolios where they control what gets served. I’m one of those people, clearly! In a post about more than just verification, Ben Werdmuller categorizes the difference as one between European and American mindsets, and that seems like a good insight.

I think also it reflects a “web vs. net” difference. Mastodon and ActivityPub strike me as an evolution of the vision of the web that reigned in the height of the RSS and blogging era—a vision that I have a lot of affinity for. By contrast, bluesky doesn’t even really have a neat way of linking to posts. Verification by HTML reflects a web-first mindset, verification by DNS reflects a net-first mindset.

Name that space!

Beside top-level verification, there’s another cool thing that DNS usernames give you: a namespace. It’s just as easy to verify subdomains with DNS records, and that demonstrates a connection between all of the “children” of a given domain name.

So far I haven’t seen many uses of this. But when I set up two of my bots on the service—ports of the old roadside and pomological bots—I decided to make them subdomains of my own handle: @roadside.xor.blue and @pomological.xor.blue, respectively. For me that’s just a neat thing, but for organizations it may prove to be an elegant way of doing delegated verification.³ Contrast that to the dozens of official New York Times Twitter accounts that share some branding and an “@nytimes” account prefix.

One neat quirk about the bluesky implementation is that the mapping from an @-username to the canonical user identifier⁴ happens right when a post is created and doesn’t break later even if the DNS records change. So if an organization verifies you as an employee—say, @sullivan.washingtonpost.com—and then you leave for a different job, old uses of your handle will still point to the correct user profile, even if you no longer use that username.

A second neat quirk is that you can have multiple DNS entries pointing to a particular user. For example, I’ve got a DNS record at parkerhiggins.net pointing to my user page, even though I’m not using @parkerhiggins.net as my username.

I think that means that you could create intentionally ephemeral DNS usernames as identifiers, and count on posts made with those DNS usernames to point to the right user. For example, you could have @editor.washingtonpost.com or @potus.whitehouse.gov point to the current occupant of that role, and preserve the meaning of references made in posts. (Twitter’s username system handles this somewhat inelegantly: all @POTUS tags point to the current president, for example.⁵)

It’s definitely worth noting here that this combination enables fun possibilities and also some more sinister ones. The namespace identification goes one way, but I’d guess many users assume some bidirectionality. If I own evilexample.com, I could imply that Alice has some affiliation with it by pointing @alice.evilexample.com right to her profile. Or I could set up @todaysenemy.evilexample.com to coordinate bad actors to a particular target.⁶

Portable in a storm

The last thing I want to focus on is the “portable” nature of domain-based usernames. That’s mostly true only in theory today, but again there are already some pretty cool knock-on effects.

The plan for bluesky and AT Protocol is eventual federation. They’ve released more information about that this weekend; the upshot is that eventually many different “blueskies” will exist, and users will be able to choose between them. A design goal is that users hopefully won’t have to think about this too much, unless they want to.

According to the plan, users will eventually be able to switch their affiliation and take their data with them. And if they’ve used their own domain as an identifier, they wouldn’t even change usernames.

That particular benefit depends on the direction the bluesky ecosystem takes. Portability matters less if there’s nowhere else to go. Notwithstanding that, though, domains-as-usernames mean good things for user portability right now.

The list of stable platform-agnostic unique identifiers for a person is pretty short. Your email address, your phone number, your social security number or similar government-issued ID. It’s worth noting that these are each pretty sensitive! But you get asked for each of them pretty frequently, because identification is important and hard to do.

Even outside of the technical promises of portability, I like the idea of allowing users to connect their identity to a less sensitive stable identifier under their control, like a domain name. This is sort of the promise of Signal’s (controversial) decision to use phone numbers as identifiers for users: when its developers were explaining their choice not to build towards federation, they argued that the “address book is now the social network.” In other words, the power of portability comes not from your ability to use another Signal server, but from you to quickly reassemble your network on a different platform altogether.

It’s a small example, but already Jesse J. Anderson’s SkyLink browser extension, which lights up when you’re visiting a domain that has a pointer to a bluesky account, feels like a step in the right direction as a tool for users that works directly through DNS.

If bluesky is one domino in the sequence that leads to my being able to use domain names as stable long-term identifiers outside of any platform’s control, I think that would be a great thing for users.

Glass Onion crossword cameo

Through some remarkably sharp eyes and impressive grid IDing, I learned that a crossword puzzle shown briefly on-screen on “Glass Onion: A Knives Out Mystery” is the June 16, 2022 New York Times puzzle constructed by me and Ross Trudeau. Some very very minor spoilers follow.

When we first re-meet Daniel Craig’s ridiculous southern detective character Benoit Blanc in this movie, he’s depressed in the bathtub, on a Zoom call with some notable puzzle/mystery celebrities. The film is set in May, 2020, and his detective business has been newly shut down by the pandemic. One celebrity on his screen asks if he’s tried crossword puzzles, which he rejects out of hand, despite the fact that several are strewn in front of him.

I happened to watch the movie in theaters and then again streamed at home, and the second time I noticed the crosswords. I didn’t even consider trying to identify them.

But then in a crossword Discord I’m in, Ben Zimmer posted a screenshot and almost immediately constructor Brian Thomas was able to identify both our grid and Pao Roy’s June 17, 2022 puzzle by the grid shapes. (Ours is a bit of an unusual grid, with left-right symmetry and a single spanner across the third row, but still, it’s an amazing feat of identification.)

See what he was working with, from the bottom right above:

There’s still a little mystery about why crosswords from mid-2022 would appear here, given that the film was wrapped in September, 2021, but if I had to speculate I’d guess that they needed to revise some of the dialog in light of the circumstances of the on-screen cameo appearances.

My LA Times crossword debut

I constructed today’s Los Angeles Times crossword puzzle — my first for a paper that my family has subscribed to for my entire life. The puzzle will be available for a week or two on the LA Times crossword page, maybe a bit longer in the archives for Puzzle Society members, and should be downloadable with a quick xword-dl lat -d 12/14/22 for a good long time. Some spoiler-y notes below!

This puzzle was in the works for a while, and the version of the grid published today is way different from what I originally submitted. That version featured a punny revealer, mostly different themers, and more traditional rotational symmetry. I’m proud of that grid, pictured here, but it didn’t quite line up with the editorial vision at the LA Times, and they asked for some revisions that required architectural changes.

With crossword themes, you’re usually shooting for “tightness”¹ and “consistency.”² But as with Set rules, you can get credit for “consistent inconsistency.” One thing I liked about my earlier theme set is that each of the paired nos worked a little differently.

I wasn’t sure there would be a way to rework the puzzle and save the concept, but after a bunch of tinkering and staring at the grid, the idea of using diagonal symmetry (a hip and edgy option employed lately to great effect by Brooke Husic and others) occurred to me. In my opinion it’s a perfect match for the content.

Throughout, I was lucky to be using some new beta construction software called Ingrid by Ryan Fitzgerald. Ingrid does a few things that were huge on this puzzle: it supports diagonal symmetry out-of-the-box, it has a built-in mechanism for “versioning” a puzzle through different revisions, and allows constructors to easily exclude word options for a given slot and see what remain for the rest of the fill.

That last one is big for avoiding heart-breaking dupe situations. For example, I didn’t want NO to appear anywhere in the grid outside of the theme. Ingrid helped me steer clear of that without having to futz with my actual wordlist or filling most of a corner only to realize I was approaching a dead end.

Anyway, I hope you enjoyed the puzzle! I had a great time making it.

Wednesday music

I watched a few episodes of the new Netflix show Wednesday. Show’s fine, and the Danny Elfman score is interesting, and I laughed when his theme first started playing and was dutifully described in the subtitles as “jauntily macabre.” If you want jauntily macabre you have to go to Danny Elfman, right?

As the show went on, I noticed that a lot of care went into the musical descriptions, so I pulled them out to look at the whole collection.¹

Some very fun ones in here! I like “delicate, cryptic”, “whimsically morbid”, “quirkily dreary”, “twinkling, wondrous”, “groovy, kooky”. The final cues before the last episode’s closing theme are “tender, wondrous”, “gentle, quirky”, into “grimly grandiose”. I haven’t seen enough of the show to know whether you could follow any of the plot through these descriptors, but I bet you almost can.

I’ve put the full list of 255 music descriptors up on Github, but as a sample here’s all of the second episode:

• eerie
• quirky
• jauntily macabre theme
• chilling
• chilling
• creepy, ornate
• tense
• tense
• dramatic
• quizzical
• plucky, excited
• whimsically morbid
• intimidating
• despondent
• mournful, dramatic
• suspenseful
• dramatic
• suspicious
• mellow
• cheekily dramatic
• pensive
• foreboding
• suspenseful
• elegant instrumental
• instrumental
• chilling
• jauntily macabre outro

Jauntily macabre indeed. I do sort of wonder at what point in the creative process those were selected. (Like: did Danny Elfman get a note that they’re looking for a “whimsically morbid” piece for that section, or did he write a piece that somebody downstream clocked as whimsically morbid?)

Tooting from the intersection of art and technology

I’ve finally taken the plunge at set up my own Mastodon instance at a dedicated domain, as has been foretold by the prophesy of my recent posts. Instead of using one of the very fun subdomains I surfaced in classic literature, though, I found one that plays on the goofy meme-y phrase about “the intersection of art and technology.” And so, my new Mastodon instance lives at tech.intersects.art. The plan is to offer accounts to a handful of friends—never a big general purpose server, but hopefully developing something adjacent to a group chat.

When I posted about the move, somebody on Twitter asked about the benefits of a smaller server, and I found myself writing enough that it seemed like a good thing to bring over here. This list is a little loosey-goosey, but maybe it will be useful to somebody considering making the mover.

• My instance is running Hometown, which is a fork of Mastodon by Darius Kazemi that introduces a few useful features that are unlikely to get merged into the main version. One that seems significant is the inclusion of “local only” posts, which I hope can help facilitate the group chat feeling. I had been familiar with Hometown before, and had read Darius’ Run Your Own Social guide, but a post from Christa really sold me on it. If you’re interested in trying Hometown, there are a bunch of public servers running it.
• There’s been a lot of discussion about moderation and defederation recently, and I think the implied Mastodon model mostly works better with smaller instances. That is to say: I like the idea of making defederation decisions by and for a small group of people (me and my friends), and I prefer knowing that my own ability to federate isn’t contingent on the moderation decisions of a big server admin. In my timeline right now are discussions about instances defederating with journa.host, an instance that thousands of journalists have recently signed up for, and the flagship instance as well. I totally respect the ability of instance admins to make those decisions, but I don’t want to get caught up on either end of it, and I think I’m less likely to in my little corner of the fediverse.
• Also it’s a funny cool domain! I haven’t had a vanity email address in a while but I’ve always respected the move. One of my favorite employee perks at my last two jobs where getting @eff.org and @freedom.press emails. My hope is that this feels like a little symbol of belonging for a handful of my buddies.
• I know the recent rush of traffic was starting to strain people’s servers, and there’s been a lot of discussion about making sure that people were chipping in to cover volunteer admin support. I only put together recently that, because of ActivityPub’s push model, posting to many followers is more expensive. Hosting my own instance means I can worry less about whether I’m a drain on somebody else’s resources.
• Similarly, I can throw money at my own instance if it starts to get backed up! I’m hosting my instance with fedi.monster, and they make it easy to bump up my installation’s resources if I need to. I’m not sure that will always be worth it, but it’s nice to have that option available.

Given all these benefits, I’d been casually hoping to migrate servers for a while now, and certainly since it became possible to transfer existing followers. I’m excited to be starting this chapter of my Mastodon usage now.