From @elfprince13 in #826 (comment):

I currently control:

• @[email protected] (personal Mastodon instance)
• @elfprince13.mumak.app (ATproto/Bluesky account)

Even a single-user Mastodon instance does not run particularly well on a small AWS instance, and it requires more attention than I want to allocate for it to constantly switch apps for posting, so I have been thinking of sunsetting the Mastodon account in favor of the Bluesky account; however, I would like to:

• retain my existing Mastodon followers if at all possible.
• continue using @[email protected] for my handle, rather than the clunkier @[email protected] which the current domain redirect support appears to require.

More background in #330 (comment), specifically that this would be a full Move-style migration, since the underlying AP actor id has to change.

@elfprince13 the other difficulty here is that we currently only support custom fediverse usernames for web sites, not Bluesky accounts. I'm reluctant to add user-level settings, since they'd require an authed UI that I don't currently have and am unlikely to build. Maybe we could do it by reading the desired username or @-@ handle from your Bluesky profile bio though.

Agreed. Bio is awkward and annoying, DNS or HTTP is inaccessible, authed UI is a burden on my end. I haven't heard a good easy (or at least not hard) answer yet. 🤷

Hey!
Thanks for pointing me to this thread 💣
I'm curious, why is DNS/HTTP inaccessible?

My 2 cents:

I don't think the bio approach is a good idea – ideally the user should verify the domain they're claiming, otherwise one could just say they're @[email protected] in their bio and there's no way to verify that, plus there's gonna be duplicates problems (2 users claiming the same domain in their bio). Also yes, it's just awkward.

What @elfprince13 proposes about checking some configuration file from domain.tld sounds ok to me and similar to what Bluesky already does. I don't know if it is technically impossible, the doc for the website -> AP bridging mentions a similar approach using the .well-known path but surely you know why it can't be used in this scenario and I don't 😛

edit: typos

We may be confusing two different things here: custom domain handles, eg @[email protected] instead of @[email protected], and custom usernames in handles, eg @[email protected]. Let's keep this issue focused on the former; I'll create a new issue for the latter.

^ done!

@frncs-eu:

I don't think the bio approach is a good idea – ideally the user should verify the domain they're claiming, otherwise one could just say they're @[email protected] in their bio and there's no way to verify that, plus there's gonna be duplicates problems (2 users claiming the same domain in their bio). Also yes, it's just awkward.

Of course. To use a custom domain in a fediverse handle, you have to serve the Webfinger redirects on it, at minimum, which you can only do if you own it.

@elfprince13 and I were talking about how to set a custom username in a fediverse handle. I'll follow up a bit on that in #1190.

^ done!

@frncs-eu:

I don't think the bio approach is a good idea – ideally the user should verify the domain they're claiming, otherwise one could just say they're @[email protected] in their bio and there's no way to verify that, plus there's gonna be duplicates problems (2 users claiming the same domain in their bio). Also yes, it's just awkward.

Of course. To use a custom domain in a fediverse handle, you have to serve the Webfinger redirects on it, at minimum, which you can only do if you own it.

@elfprince13 and I were talking about how to set a custom username in a fediverse handle. I'll follow up a bit on that in #1190.

Sorry for the noise, all clear now! Thank you!

Now that we support DMs/chat, we could let people DM us the domain they want to use for their bridged fediverse address. Easier than a custom authed UI.

Realistically, Bluesky accounts bridged into the fediverse will always start on the @bsky.brid.gy domain. So, the next step here is either

1. Migrate the account from [email protected] to @domain@domain with Move
   OR
2. Delete the old account and start the new one on @domain@domain fresh.

1 is more work, but not too much, and obviously preferable.