Add support for alias handles

[seanthegeek]

Is your feature request related to a problem? Please describe.

The Bluesky verification guide warns:

If you change your default Bluesky username (with the .bsky.social suffix) to a website URL, your old username will be available for someone else to use. However, any tags or mentions with your old handle will still point to your account. If you'd like to keep your old .bsky.social username, we recommend creating a second account to hold that username.

This is not an ideal situation. Creating a second account to stop people from squatting on your old .bsky.social username creates confusion about which account users should follow or mention.

After X started charging $100/month for API access, X migration tools had to switch from using the X API to using a browser extension that pages though a list on the following page, where profile data can be truncated. Migration tools like the Sky follower Bridge search for matching Bluesky accounts based on an X handle ending with .bsky.social. If your Bluesky account handle does not match your X handle because your Bluesky handle is a domain name, the author of Sky Follower Bridge recommends making sure the display names at least match so it can still find your account that way.

Describe the solution you'd like

Ideally, the old .bsky.social handle would be an alias of the domain name handle, with the domain name handle being the primary handle, with a maximum of one alias allowed per account to prevent abuse. That solves many problems.

1. Prevents malicious squatting on default domains
2. Allows a user to retain a commonly used username (e.g., I use seanthegeek everywhere) without needing to create an empty placeholder account
3. Makes migration from X to Bluesky easier

Additional context

I wrote a blog post discussing the advantages and disadvantages of Bluesky's verification process here.

[seanthegeek]

Actually, it looks like the did:plc specification already supports multiple aliases

• alsoKnownAs (array of strings): should include an at:// URI indicating a handle (hostname) for the account. Note that the handle/DID mapping needs to be validated bi-directionally (via handle resolution), and needs to be re-verified periodically

So maybe this issue needs to be opened on the PDS project instead?

[bnewbold]

Hi @seanthegeek!

Indeed, flexibility around DID/handle mappings, and the ability to retain (or at least "freeze") old *.bsky.social handles when changing to a custom domain handle, have been frequent requests and on our planning list for a long time now. One of many important areas to improve on.

One simple feature would be the ability for accounts on Bluesky PDS instances to reserve one *.bsky.social handle when they configure a custom domain handle. This would remove a lot of anxiety and impersonation issues around that configuration change, even if the reserved handle is not functional.

Another mitigation would be to "freeze" handles for some time period after a transition (unless transferring back to the original account). For example, a few days "cool down" period. This would reduce rapid-follow impersonation and handle "stealing".

Having multiple handles registered in the DID document alsoKnownAs list is more fraught. There are some strong arguments for (eg, validation of multiple affiliations), and arguments against (user confusion of having multiple names at the same time, need to frequently verify an arbitrary number of domains, etc). Whatever we end up deciding on for handles, we intend to allow bi-directional account verification in other ways as well, such as linking a Matrix account or ActivityPub account to an atproto identity.

For now I would point folks to the existing mitigations and work-arounds. These are fairly high-priority changes, which would save us a ton of time doing support requests and dealing with impersonation cases, but they also require updates to the core identity system, and we have a lot going on right now.

[seanthegeek]

Hmmm. great points. Perhaps of a variation of the first option mentioned would be best. Reserve a *.bsky.social` handle when switching to a domain handle, except allow that handle to only be functional as a redirect to the verified handle when looking up profiles directly (not as mentions, for example). Sort of like Wikipedia's "redirected from" pages. That way it can't be impersonated, and it's easy for newcomers to find the people they want to find based on that person's common username on other platforms like X and GitHub. Personally, I'm against multiple fully functional handles because of the complexity and confusion issues you mentioned.

[seanthegeek]

I also want to thank you and the rest of the Bluesky team for all of the work you have done to build this amazing platform and scaling up to handle a massive wave of newcomers amid the mass migration from X. I can't imagine the development, operational, and moderation workloads.