AP and web => ATProto: Support custom handle domains for bridged accounts

[jfietkau]

Suppose I have an ActivityPub account @alice@example.com that I intend to use to interact with Bluesky users via Bridgy Fed. I gather that if I do nothing in particular, my AT/Bluesky handle will be alice.example.com.ap.brid.gy.

Suppose further that I have administrative control over example.com. I can add DNS records, set up selective resource proxying, etc. What are my options for using a custom domain for the account handle?

Going by the Bluesky documentation on custom domain handles, I should be able to use @example.com as my handle by adding a DNS record containing my DID. Is this the case for accounts bridged by Bridgy Fed as well? I assume that my account's DID will be created automatically by Bridgy Fed whenever I first interact with a Bluesky account through it. Is there a way to find the Bridgy Fed DID corresponding to my AP account early or do I need to wait until Bluesky enables federation?

The Bridgy Fed documentation states that I have the option to use @alice.example.com as my AT/Bluesky handle if I proxy selected /.well-known requests to Bridgy Fed. Are the precise requirements for this process documented anywhere yet?

For either solution: is there a way to test it, or generally see what my bridged AT profile would look like before Bluesky launches federation, or should I just wait?

[snarfed]

Thank you for filing! Really great sleuthing and thinking here. You're a bit ahead of me!

I expect/hope to make custom handles like this possible on accounts bridged to Bluesky. I don't know if that will ship on day one of Bluesky support, and it's not my top priority right now, since I can add it and not change those bridged accounts' identities, but if/when it does, it will work largely as you've described.

(The link to the BF docs you mentioned is more developer design doc than user-facing feature documentation, hence including some...that aren't launched here, or even fully implemented or thought through yet, and Green parts have been implemented and running here for years, the rest are still in the early design phase.)

I'm currently prioritizing the fediverse equivalent a bit more because I can't add it after the fact transparently. If someone starts out as @example.com@bsky.brid.gy, and then later I change them to @example.com@example.com, that's a whole new fediverse actor and account.

[snarfed]

The one key issue with custom handles I'm still not sure about is identifying which bridged account for a given domain to use. For example, if someone has a web site on example.com and a native Bluesky account with handle example.com, and they redirect Webfinger to Bridgy Fed, which of those two should it bridge into the @example.com@example.com fediverse account?

Fortunately, this isn't a problem for all networks. For Bluesky, each bridged account would have a different DID, and if you validate your handle with DNS, you'd put the DID you want in the DNS record. It might still be a problem if I let people redirect /.well-known/atproto to BF and have it do HTTPS handle validation instead, but I haven't gotten that far into the design yet.

[jfietkau]

Thank you for the clarification! Sounds like for now all I need to do is wait. 🙂 My understanding of AT is very superficial, so I'm glad to hear I was on the right track.

For example, if someone has a web site on example.com and a native Bluesky account with handle example.com, and they redirect Webfinger to Bridgy Fed, which of those two should it bridge into the @example.com@example.com fediverse account?

That's a good question, especially given that people with only a website or only a Bluesky account with a custom domain handle might add the other one at any later date. Off the top of my head, I can't think of a better solution than picking an arbitrary priority and giving the second account in line a suffix.

[snarfed]

Related: #821

[elfprince13]

Following up on this with a closely related scenario (originally posed in a Bluesky post).

I currently control:

• @elfprince13@mumak.app (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 @elfprince13@mumak.app for my handle, rather than the clunkier @elfprince13.mumak.app@elfprince13.mumak.app which the current domain redirect support appears to require.

[snarfed]

Thanks @elfprince13! Sounds like you're hoping for this issue (custom domain handles for Bluesky bridged accounts), plus custom ActivityPub usernames (already supported for web sites), plus #330.

[jfietkau]

Taking the liberty to rewrite this issue's title to clarify that I'm talking about ActivityPub accounts bridged into ATproto. I don't know to what extent @snarfed will want to work on custom handles for both directions at the same time, but the AT => AP use case might warrant a separate issue.

[snarfed]

Thanks @jfietkau! Yeah Bluesky => AP is #1150.

[elfprince13]

Yes sorry - my brain was apparently in mirror world when reading this thread first time through. -- ~Thomas

[Fauli1221]

I personally am interested in this
I have a AP account @twitchtrot@hooves.social and a AT twitchtrot.horse and I want to migrate twitchtrot.horse into a mirror of @twitchtrot@hooves.social while keeping all the followers and the handle
Will that be possible at some point?

[snarfed]

@Fauli1221 it's a great idea! We've discussed it in eg #330 (comment) . It's arguably outside Bridgy Fed's scope, but it could be a good idea for a new service that uses a lot of BF's (and its libraries') guts under the hood, since it's all open source.

[thomasjwebb]

I would really love to see this implemented. I'm also wondering if this will require having control over the fediverse server in question, e.g., my own solo Mastodon instance or my WP blog or would it be possible for any Fediverse account? I already have a custom AP domain setup but never use my bsky account. I would love to turn that handle into just a proxy for my Fediverse account.

[snarfed]

@thomasjwebb you probably won't need to own your fediverse server. I expect all you'll need is DNS control over the domain you want to use as your Bluesky handle.

[snarfed]

One question here is how a fediverse user would tell Bridgy Fed the domain they want to use for their Bluesky handle.

One option is a link in their fediverse profile. Another option is a DM.

[Fauli1221]

I think a command system using dm's would be great in general and could be used for other things as well

[jfietkau]

Please have mercy on my profile link list. Since Mastodon limits them to four by default, I have none to spare. 😮

Yes, a DM would make intuitive sense to me as well. Assuming you're not eager to build a web UI, it's the only good channel I can think of.

Thinking out loud: Maybe when an AP user newly follows the bridge, you could check their AP domain for an ATproto DNS entry automatically. This might be a convenient process for single-person servers like mine. We have to add our BridgyFed DID to the DNS record, right? So there'd be no danger of impersonation. Then again, even if you do that, you'd also still need a process that can be triggered later for when people change their mind or learn of the possibility only after following.

[qazmlp]

There'd likely still need to be a bit of authorisation in DNS or /.well-known/… to specify which AP account is allowed to take the handle (DNS would likely be easier for most, but may have too much lag for automation), but checking that automatically (maybe also for user.domain subdomains) would be interesting for instance-opted-in places that can set that up automatically, too.

[snarfed]

Yup, all of these "claim a domain/username" flows have to be bidirectional and checked both directions. Fortunately for Bluesky handles, that's already specified by ATProto, you have to put your DID into an _atproto.[domain] DNS TXT record.

[thomasjwebb]

Having a DM command system would solve other problems too. Like having another way to stop the bridging other than blocking the bridge, which seems kinda clumsy and drastic to me.

[snarfed]

Yes! That's already supported, you can DM no to the bridge account to disable it. We just don't document that as loudly as blocking it.

[thomasjwebb]

Ah nice! Yeah I just didn't know that, so the DM command mechanism is already there.

[Fauli1221]

Yes! That's already supported, you can DM no to the bridge account to disable it. We just don't document that as loudly as blocking it.

instead of just saying no I would recommend making it so that the commands are something like this
!stopbridge
!getdid
!setdomain
!invite

with that it makes it more clear what is a command and then having the bot always reply giving you the feedback where you know it worked

[snarfed]

Hah, yes! I deliberately haven't documented or wordsmithed the perfect command name(s) for DMing the bridge, beyond the current (mostly undocumented) yes to enable it and no to disable it, because there's a lot of UX value in officially having just one way to do things, not multiple.

[karcsesz]

We've been detected! Abort! Abort!

All kidding aside, seems to be working fine minus a small visual bug:

it replies with the old username when it has actually successfully configured the new one

Will keep an eye out for gremlins to report ^^

[Fauli1221]

The stuff on Hooves was me. my experience was basically same as @karcsesz reported
Some visual oddities besides that everything worked well

Thanks for the amazing work and I hope you have fun polishing the feature ^^

[jfietkau]

I have joined the ranks as well. Gonna leave it to @snarfed to decide when to consider this issue resolved, but I'm satisfied. 🙂

[thomasjwebb]

Woohoo! Working for me too (with same issue noted by others).

[RoblKyogre]

nice, got it working with my own domain :3

one thing i’ll note, the bot kept responding with instructions to set up my did and did not move my handle to my domain, despite me having my did set up in the .well-known/atproto-did. However, once I’d set up the DNS record instead, it worked then.

[snarfed]

@RoblKyogre hmm! https://roblkyogre.craftingcomrades.net/.well-known/atproto-did , right? That currently serves Content-Type: application/octet-stream. It needs to be Content-Type: text-plain instead. https://atproto.com/specs/handle#handle-resolution

[RoblKyogre]

@RoblKyogre hmm! https://roblkyogre.craftingcomrades.net/.well-known/atproto-did , right? That currently serves Content-Type: application/octet-stream. It needs to be Content-Type: text-plain instead. https://atproto.com/specs/handle#handle-resolution

ahhh thanks for pointing that out, did not think to check that! Incidentally, before I did the DNS method, the handle debug listed the HTTP method as valid, and I saw that going to my profile would indeed go to the bridged profile, so not sure bluesky is doing type checking on that file. :p

[snarfed]

Incidentally, before I did the DNS method, the handle debug listed the HTTP method as valid, and I saw that going to my profile would indeed go to the bridged profile, so not sure bluesky is doing type checking on that file. :p

Thanks for the nudge! https://bsky-debug.app/ isn't really an official tool, but looks like you're right regardless. From https://atproto.com/specs/handle#handle-resolution :

The response Content-Type header does not need to be strictly verified.

...and sure enough, the appview validates handles with the HTTPS method without Content-Type: text/plain. OK! I'll remove that check here too.

[snarfed]

OK everyone! Docs are up, DM text is finalized, I think this is good to go, at least as a beta. Feel free to try! https://fed.brid.gy/docs#bluesky-enhanced (shift-refresh if you don't see the new docs yet)

Also, the bot accounts now have a more complete DM interface, including an honest to god help command. Feel free to try it! https://fed.brid.gy/docs#dm-commands

[Tamschi]

There's quite a bit of delay, but help seems to work.

Two observations from Bluesky:

• The message contains _ _ formatting, I assume because it's supposed to be in italics on fedi.
• * _username [domain]_ : set a custom domain username (handle) doesn't seem like it should appear on the Bluesky side.

[Tamschi]

Hi! I'm a friendly bot that can help you bridge your account into the fediverse. Here are some commands I respond to:

  * _start_ : enable bridging for your account
  * _stop_ : disable bridging for your account
  * _username [domain]_ : set a custom domain username (handle)
  * _[handle]_ : ask me to DM a user on the fediverse to request that they bridge their account into Bluesky
  * _help_ : print this message

I think instead of [handle] it would be better to write [@handle@example.com] in the ap.-account's help, since Bluesky users won't necessarily be familiar with the fediverse handle format.

Similarly, the bsky.-bot should probably use an example like [@handle.example.com].

[snarfed]

Thanks! You're right, the help text from @ap.brid.gy on the Bluesky side right now is indeed a bit half baked, both formatting and text. I do plan to support custom handles in that direction soon, #1150. And protocol-specific example handles are a great idea!

The delay is inherent, sadly, there's currently no way to listen for Bluesky DMs in real time, I have to poll. I currently do that every 60s.

[TomCasavant]

Is it possible to send a notification when it successfully changes the username? I thought I had misconfigured something w/ one of my accounts on my end til I checked bluesky this morning haha

Also, I know bridgy automatically converts '_' to '-', is that a restriction because of how AT resolves the username or something in Bridgy? And if it's because of AT, can that be added to an error message to users attempting to set their username with an underscore? it completely slipped my mind this morning and wasn't immediately clear based on the default error message what the real issue was.

Edit: My guess is that the underscore is actually allowed in an _atproto.username TXT record but I haven't tried it

[snarfed]

Hi Tom! It changes your handle (ie updates your DID doc and emits an #identity event) synchronously, so when you get the reply, BF has already done everything it's going to do. Usually it takes effect more or less immediately on Bluesky's side, but I guess sometimes it can take a bit of time.

Re _ vs -, ATProto handles don't allow _s: https://atproto.com/specs/handle#handle-identifier-syntax . And yes, DMing people troubleshooting info is a great idea! That's #758 and somewhat #1403.

[TomCasavant]

so when you get the reply, BF has already done everything it's going to do

Sorry, I meant I didn't get any reply when I sent the username message and everything was already configured correctly. So I don't need a message when it changes on bluesky's end, just when it didn't run into any issues verifying the did:plc

[snarfed]

Marking complete! 🎉

[snarfed]

Sorry, I meant I didn't get any reply when I sent the username message and everything was already configured correctly.

Ah! Good point, we don't send a reply in that case now, but we definitely could.