Option to redirect from the bsky.social handle to a custom domain instead of freeing the bsky.social handle

[rubenlg]

Describe the Feature

According to the documentation: "Note: if you change your default Bluesky username (with the .bsky.social suffix) to a custom domain, your old username will be available for someone else to use."

This isn't ideal because of bad actors seeking to impersonate businesses. While some people might prefer freeing the old {USERNAME}.bsky.social ID, others who use {OFFICIAL_COMPANY_NAME}.bsky.social might prefer holding onto their original ID to avoid impersonation.

Could we add an option to preserve and redirect the original .bsky.social username when switching to a custom domain? This would let users choose whether to release or retain their original username, helping prevent impersonation while still giving flexibility to those who want to free up their old username.

Attachments

No response

Describe Alternatives

The alternative is to create a separate account after transitioning to the custom domain, for the sole purpose of reserving the ID, maybe with a profile description that points to the custom domain. But it sounds wasteful in terms of resources.

Additional Context

No response

[Tamschi]

I think this (along with matching redirects of nested URLs!) is important to encourage users to move to a custom domain handle.
It's also important that the user can then switch back to the redirected handle later on, if necessary.

(It likely would do wonders for domain handle uptake if the process was that smooth and reversible. The current method is a little scary even from my tech-affine perspective.)

[madeindex]

This seems like a big issue that many people are interested in!

There are so many questions the feature leaves one asking.

Such as, what would happen to the link to this issue on Bluesky? https://bsky.app/profile/madeindex.bsky.social/post/3lacl6scs4i26

After a name change, the old name or links should simply 301 redirect to the new ones. That is also the method recommended by the World Wide Web Consortium (W3C)

[trivikr]

I know folks who created BlueSky accounts before custom domains were available, who are reluctant to migrate to avoid their existing <handle>.bsky.social to be impersonated.

Some of them are choosing to create a dummy account which follows the custom domain to avoid impersonation. But that shows two BlueSky accounts with the same name in search results.

I feel the redirect from the bsky.social handle to a custom domain should happen automatically when someone migrates.

[chylex]

If this is implemented, what happens with the existing dummy accounts? I just created an account, and I don't know if it's better to wait for the redirect, or create a dummy account now with the expectation that I'll be able to merge the accounts later.

[Tamschi]

This is somewhat relevant: #5303
It seems like the team is at least aware of the issue.

[volcanodiscovery]

It seems an important (missing) feature to me. I would propose that every account gets a .bsky.social handle, which always serves as the primary identifier and always resolves to this account, while a custom-domain handle should be an optional alias that is simply shown instead and can be used to resolve to the original handle.

[Tamschi]

That's not necessary, there already is a stable identifier (usually) of the form did:plc:….
That's surfaced sometimes when you use the share link feature on Bluesky, since that's how you make permalinks on Bluesky.

What's needed is 'just' reserving the second handle and having it continue forward to the account.
(Of course this is a quite bit more complicated in practice than me writing that down, but doesn't sound terribly difficult at least for someone already familiar with the system.)

[climatebrad]

This is a very important safety and security feature.

[janaka]

there has been discussion about this since early/mid last year iirc. Surprised 1) not to find an older issue tracking it 2) only 30 👍🏾.

Hopfully, the bsky team gets to this soon ish.

I'm holding out. I don't want to give up my vanity bsky.social handle :)

[trivikr]

I'm also holding on my vanity.bluesky.social handle.

Post a skeet on your BlueSky account requesting followers who would like this feature to 👍 .
That will give data to BlueSky team to prioritize this feature request.

[janaka]

also just found this https://bsky.app/profile/jacob.gold/post/3kh6re46yd42k

[volcanodiscovery]

also just found this https://bsky.app/profile/jacob.gold/post/3kh6re46yd42k
Unfortunately, this isn't a solution: Setting CNAME on the domain seems to require to actually use the same custom (sub)domain as handle already and giving up on the bsky handle.

[trusktr]

This would be a nice feature.

For now the workaround is to create a second account with the bsky.app username but it requires a second email address. For example:

• https://bsky.app/profile/joe.trusktr.io
• https://bsky.app/profile/trusktr.bsky.social

Do it as soon as you switch to a new domain username, and most likely someone won't snipe your username, unless you're so popular that someone set up a bot to snipe it as soon as you release it.

Having an official option will prevent people/bots from sniping the name.

[trusktr]

Another good reason to have this feature would be that, if people mentioned you with your old bsky.social username before you migrated to a custom domain username, we'd want those links to still go to the same user.

For example it would be great if after someone migrated from @foo.bsky.social and @foo.domain, both would link to the same profile, and any posts that mentioned the old username would not be broken.

[Tamschi]

Another good reason to have this feature would be that, if people mentioned you with your old bsky.social username before you migrated to a custom domain username, we'd want those links to still go to the same user.

For example it would be great if after someone migrated from @foo.bsky.social and @foo.domain, both would link to the same profile, and any posts that mentioned the old username would not be broken.

That already works. The mentions use DIDs internally, which don't change when the handle does.

[volcanodiscovery]

But it would not work for links from outside that use the old handle. I think there's no way around other than keeping the bsky handle connected as failover once the user changes it to a custom domain.

[codybrom]

I appreciate the thoughtful perspectives shared here and the valid concerns being raised. That said, I’d like to respectfully offer a different take.

Former handle reservation, especially in the federated, multi-server future envisioned for the AT Protocol, feels like quicksand, with potential for unintended long-term consequences. While the intent to prevent impersonation is understandable, allowing custom domain users to also hold an additional .bsky.social handle risks repeating the same mistakes seen on early Twitter and other centralized platforms. Without strong guardrails, Twitter’s single namespace enabled early users and parody accounts to take advantage of notable names, leaving many unavailable to their expected owners. But handles alone are inherently imperfect, and anyone can create similar or derivative alternatives, which on Twitter led to the proliferation of @real____ and @official____ handles that, ironically, some may want to preserve when transitioning to Bluesky.

The AT Protocol’s support for custom domain handles is a clear and robust solution, and I don't think anyone in this issue disagrees. Tying identity to a domain allows users to establish unique, verifiable identities on any server without needing to reserve handles across the ecosystem, so the only real challenge is when an account moves between domains. But in the case of reserving your previous non-custom name, isn't that ultimately a temporary issue?

Mastodon has already demonstrated that tools like rel=me verification and domain-linked handles work well without requiring users to constantly chase handle reservations across new instances.

If we allow for passive handle reservations now, what about when additional AT Protocol servers pop up? By supporting some amount of official handle squatting, aren't we encouraging mass handle squatting when new AT Protocol servers emerge? What about instances that exist to squat handles en-masse? The solution isn't replicating the past with long-term handle squatting, but better verification.

From a UX perspective, if you search for a notable name and get multiple results, the solution shouldn't be finding which one ends in .bsky.social, but which one offers the clearest “verification” that it is who it says it is.

For this reason, it's my opinion that more priority should be given to additional verification features and benefits that enhance trust in searches and profiles. A public record of former handles, for example, could allow labelers to clearly indicate when a handle had previously moved to a new DID or re-registered by a new account. Labelers could also flag when the same or similar handles existed across multiple domains, providing additional clarity and confidence for users. Another option could be a form of social verification, where if two accounts follow each other, they can also trade private keys offline to mark the other as a verified connection, with an ability to display verified connections on their profiles.

I know this perspective differs from others here, but I hope it adds value to the conversation. The AT Protocol’s strength lies in its openness and scalability, and it’s critical to embrace those advantages rather than carry forward the baggage of the past.

[janaka]

@codybrom thanks for sharing these perspectives. I didn't think of the additional AT Protocol servers popup scenario because I'm not very familiar with the AT Protocol. Therefore obviously cannot comment - this might give me a bit of incentive to look up this aspect :) . Definietly appreciate the learn from other platform mistakes view. My vanity driven want to hold by bsky.social handle is definitely influenced by how handle registration on those social platforms have panned out. this does include domains. I want janaka.com but it's not been available for the last 25yrs. The person who has it isn't even a Janaka though to be fair isn't squatting, there's some logic to him registering it in the past. The point, Internet domain names are the grand daddy of squatting. So from my naive understanding it doesn't solve the problem anyway. So bsky would be just transferring the problem elsewhere anyway - and i don't know how far bsky should go to solve this either. Again, I'm taking the pure vanity view of this but do appreciate the instant verifiability that comes with a domain for products and organisations. But less so for individuals.

[codybrom]

"Internet domain names are the grand daddy of squatting. So from my naive understanding it doesn't solve the problem anyway. So bsky would be just transferring the problem elsewhere anyway..."

You're so right. Domain squatters are absolutely the OGs of this, but you're bit about "transferring the problem" points to an important lesson about that fact. Like domains, Bluesky explicitly SHOULD transfer that problem to a neutral space. Let me explain...

Both the AT Protocol and the Domain Name System (aka DNS) are decentralized, but while domain squatting is an annoying and frustrating challenge, it hasn’t broken the Internet either. Instead, everything remains functional because it doesn’t depend on a single namespace or central authority to assign names. Like the AT Protocol has Bluesky Social PBC, DNS has its own root authority, the Internet Corporation on Assigned Names and Numbers (ICANN).

Even though ICANN oversees the system and ensures its stability, it doesn't micromanage individual disputes or ownership claims. Instead, it delegates authority to registrars and dispute resolution providers, who handle thousands of cases each year. These arbitration systems, paid for by disputing parties, resolve conflicts over intellectual property and domain ownership without ICANN stepping in directly. What’s great for Bluesky is that these systems already exist. Bluesky doesn’t need to create its own resolution infrastructure because users who want custom domains are already operating within ICANN’s established ecosystem. This allows conflicts to be handled independently of Bluesky or the AT Protocol.

The AT Protocol and Bluesky should follow these same principles. Trying to guarantee permanent ownership of extra .bsky.social handles risks turning it into even more of a default namespace than it already is, centralizing the ecosystem and making it harder for additional servers or services to successfully launch and grow. Instead, more focus needs to be on verification and transparency, so users can establish trusted identities without a handle availability bottleneck. With verification that works well, handles can simply be vanity pieces. That way, if a handle changes hands, it won’t matter who owns it as long as users remain easily verifiable. This is how a system stays decentralized, scalable, and fair while avoiding the pitfalls of centralized platforms.

[janaka]

yeah, agree with your point about delegated authority/management throughout in DNS is definitely better than entirely centralised. And I do like how that works with DNS, it's neat. DNS also doesn't prevent you from having multiple records pointing at the same resource. Of course the resource needs to accept each also for it to work (mostly).

[rubenlg]

This feature doesn't make handle squatting any easier. You still need to create a Bluesky account before you can move it to a custom domain.

The real concern here is impersonation. Here's why: While Bluesky's internal system keeps all the platform links working properly when someone changes domains, that doesn't help with external links from across the internet. Think about a celebrity or known organization that's been using a bsky.social handle for months - their account has probably been linked from countless blogs, news sites, Wikipedia pages, and other social networks, to name a few. Some of these links can be updated easily, but many can't.

That's where the real value lies for impersonators. It's not just about having a handle that reads famous_person.bsky.social - it's about controlling where all those external internet links lead to.

Given that handle reservation doesn't solve anything for fresh accounts, one option might be to add a minimum time requirement before allowing someone to keep their bsky.social handle when moving to a custom domain. After all, if an account has only existed for an hour, there's no real risk of external links breaking (or becoming targets for impersonators seeking that traffic). This would help prevent people from quickly creating accounts just to reserve handles before switching domains.

Does this make sense?

[climatebrad]

Agreed. I recognize the point made earlier about not making bsky.social accounts reserved. In that case the solution needs to be more normative - the process for setting up a verified handle should be much more clear and people onboarding should be encouraged to set up that before they post. In fact I could imagine an onboarding process for people who desire a verified account from the start that clearly indicates that the bsky handle is a throwaway one that shouldn't look like your eventual real handle, but is just there to give you access to a bsky did etc.

…

On Mon, Nov 25, 2024, 8:42 AM Rubén López ***@***.***> wrote: This feature doesn't make handle squatting any easier. You still need to create a Bluesky account before you can move it to a custom domain. The real concern here is impersonation. Here's why: While Bluesky's internal system keeps all the platform links working properly when someone changes domains, that doesn't help with external links from across the internet. Think about a celebrity or known organization that's been using a bsky.social handle for months - their account has probably been linked from countless blogs, news sites, Wikipedia pages, and other social networks, to name a few. Some of these links can be updated easily, but many can't. That's where the real value lies for impersonators. It's not just about having a handle that reads famous_person.bsky.social - it's about controlling where all those external internet links lead to. Given that handle reservation doesn't solve anything for fresh accounts, one option might be to add a minimum time requirement before allowing someone to keep their bsky.social handle when moving to a custom domain. After all, if an account has only existed for an hour, there's no real risk of external links breaking (or becoming targets for impersonators seeking that traffic). This would help prevent people from quickly creating accounts just to reserve handles before switching domains. Does this make sense? — Reply to this email directly, view it on GitHub <#5904 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQVQHWAHBDH5LSGTTXCYKT2CMSKVAVCNFSM6AAAAABQM5CB22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJYGA2TKMJRHA> . You are receiving this because you commented.Message ID: ***@***.***>

[corywright]

As I see it, there are two primary issues with being unable to retain the original username/handle:

First, as we know, after your handle is released imposters can claim it. For example, as of this writing, even though @nytimes.com is now an official handle on Bluesky, nytimes.bsky.social is again available for a squatter or imposter to grab. Same for @washingtonpost.com and washingtonpost.bsky.social. cnn.bsky.social is taken, but is it held by CNN or someone else holding on to it to later spoof CNN?

Second, for organizations who need to maintain inbound links for previously used bsky.social handles, after renaming a handle they need to then create another separate bsky.social account to claim the previous handle. This leads to unnecessary account creations, and accounts whose only purpose will be to point visitors to the new handle. This is my own reason for being involved in this issue. I created and used the superchargeinfo.bsky.social account for 16 months before deciding to change the handle to our project name, @supercharge.info. External links to the old handle need to provide a reference to the new handle, so I had to create a second account to reclaim the old handle for the sole purpose of information visitors of our new handle. This account will count towards Bluesky statistics even though it will never be used.

The ideal solution, IMO, would be to retain the original handle but have all inbound requests for the old handle redirect to the new handle.

[climatebrad]

It looks like Bluesky is in fact quietly doing something on the backend for "special" users - if you try to create a @nytimes.bsky.social account, you get the error "Reserved handle".

…

On Mon, Nov 25, 2024 at 10:29 AM Cory Wright ***@***.***> wrote: As I see it, there are two primary issues with being unable to retain the original username/handle: First, as we know, after your handle is released imposters can claim it. For example, as of this writing, even though @nytimes.com is now an official handle on Bluesky, nytimes.bsky.social is again available for a squatter or imposter to grab. Same for @washingtonpost.com and washingtonpost.bsky.social. cnn.bsky.social is taken, but is it held by CNN or someone else holding on to it to later spoof CNN? Second, for organizations who need to maintain inbound links for previously used bsky.social handles, after renaming a handle they need to then create another separate bsky.social account to claim the previous handle. This leads to unnecessary account creations, and accounts whose only purpose will be to point visitors to the new handle. This is my own reason for being involved in this issue. I created and used the superchargeinfo.bsky.social account for 16 months before deciding to change the handle to our project name, @supercharge.info. External links to the old handle need to provide a reference to the new handle, so I had to create a second account to reclaim the old handle for the sole purpose of information visitors of our new handle. This account will count towards Bluesky statistics even though it will never be used. The ideal solution, IMO, would be to retain the original handle but have all inbound requests for the old handle redirect to the new handle. — Reply to this email directly, view it on GitHub <#5904 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQVQHSRMB5KIG4MOMSMD7T2CM637AVCNFSM6AAAAABQM5CB22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJYGMZTGNRRHE> . You are receiving this because you commented.Message ID: ***@***.***>

[surfdude29]

It looks like Bluesky is in fact quietly doing something on the backend for "special" users - if you try to create a @nytimes.bsky.social account, you get the error "Reserved handle".

Yes, nytimes is on the list of "famous" account names that they reserved to prevent impersonation:

https://github.com/bluesky-social/atproto/blob/1e367cba2bd1ff5560c2ec5c2a5d348cd9342b65/packages/pds/src/handle/reserved.ts#L942

[janaka]

what is bsky's stance on all this? sorry, not sure who's giving their personal opinion vs bsky's stance.

having looked into atproto identity and DID I still don't understand arguments against aliasing. This is to solve the want to retain janaka.bsky.social and add janaka.dev, janaka.co.uk, one day janaka.com as alt handles to my account. I'm not talking about solving the famous_person.bsky.social squatting problem. I'm also not talking about any pre-account creation, the flip of squatting. assume bsky.social handles are first come first serve - all the other Janaka's that would want janaka.bsky.social, sorry. Just like on twitter, I was too late.

The handle is a friendly alias for the did:plc anyway. the field is literally called alsoKnownAs. so far i can see some UX stuff to be thought through like which alias to display as the handle, which is the primary (one solution: let the user pick and make that the first in the list). Maybe limit to the bsky.socal handle + 1 or 2 more. But I don't get the problem with supporting handle alias.

@codybrom

Trying to guarantee permanent ownership of extra .bsky.social handles risks turning it into even more of a default namespace than it already is

I think i get what you are saying here. but as you say, it is the default at the moment, that ship has sailed. again to famous person / org issue is a separate issue with some common ground.

I take you point about the complication if/when a bsky2.social comes up. I personally don't expect janaka.bsky2.social to exist out of the box. then we get into the whole Mastadon and Discord type situation. Discord has had to paper over a lot of this to improve the UX.