Fediverse => Bluesky: automatic custom domain handles for all users on an instance #1537
Comments
snarfed
added
the
feature
|
I would definitely shorten my username if I could! |
|
|
Uh... I'm not sure I understand, but does this mean that you change the domain of the original account and bridge to the existing account instead of the bot account? |
|
@wbz0100 maybe this will help: https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial For Bridgy Fed specifically, it just changes the handle (ie domain ie username) of the bridged Bluesky account. The account itself stays the same. |
|
Was looking at these options and I think I have an idea of how to implement this broadly and easily. It does require some cooperation from whomever is operating the domain and might vary a little based on the webserver they're using, but they could either use reverse proxy (such as via nginx) or a tiny little php stub that takes a call on the HTTPS verification url and just reverse proxies that to the bridge. So something like: Then shiri.bsky.foggyminds.com/.well-known/atproto-did will reverse proxy something like bsky.brid.gy/httpsdid/[email protected] to spit out the correct DID for the bridge. And for the bridge to know what names to use, the DNS could have a TXT record like _bridgyfed.foggyminds.com = bsky.foggyminds.com (telling it that everything @foggyminds.com should be converted to .bsky.foggyminds.com) This feels like it would be relatively minimal on the side of the bridge, can even be done in parts. The first simplest part alone means that an admin can just tell their users to message the bridge username .bsky.foggyminds.com to switch their names. No need to try and auto-convert users, but on new connections it can just have an added check to the TXT record. Maybe a dummy account just to test it before doing anything else (ie. it'd call verify_bridgyfed.bsky.foggyminds.com which would ideally reply with a generic proof line). From there we can easily set up our own wildcard ssl certificates (as well as forwarding web requests to the appropriate bluesky profile page) |
|
I was thinking of implementing this myself for users of my akkoma instance but it would be great if bridgy fed helped with the process too. What's annoying about the protocol though is you either need something in the DNS or to run a server that has a wildcard ssl cert or makes an ssl cert for each subdomain. |
|
This could be related to the instance opt-in implementation #1305. when a new user is added to an instance, bridgy could respond with a users DID once its created and the instance would be responsible for properly setting up one of the mechanisms. The instance when opting in would have to tell bridgy if they use a custom domain and if they do, Bridgy automatically sets the new user handle without having to message I currently have a proof of concept implementation of this via a custom nameserver that queries the bridgy dns for a users DID and then dynamically creates the appropriate TXT record for the domain. So for example if you have EDIT: PoC I mentioned: https://gist.github.com/S0yKaf/05fb63a317a9a3c191d6ce770848a754 |
Whoa, exciting! This all makes sense. The catch is that the instance and/or actor needs to auth itself to Bridgy Fed, so that you can't set your domain to a random bridged fediverse user and change their bridged Bluesky handle to your domain. The current DM approach does this by requiring that the incoming DM ActivityPub activity, like all activities, has an HTTP Signature generated by the actor's key. @S0yKaf sounds like you're comfortable hacking around your instance, any chance you could try generating those DMs programmatically? |
This was my initial idea. It's definitely possible to automate both this and #1305 via sending DMs programmatically. I mostly wanted to discuss the possibility to have the feature be done in a more official manner.
If bridgy had a way to verify a domain, would the handle takeover scenario remain possible? @shiribailem mentioned a domain could setup a custom TXT record to let bridgy know what domain it should associate users with.
Are there any issues with this solution? As far as I can tell there wouldn't be any security implications with verifying a domain in such manner. I'd be willing to spec out an implementation for this DNS verification if its an adequate solution. |
Right! Good point. If the users' custom domain handles are under the same origin domain as the fediverse instance itself, modulo https://publicsuffix.org/ etc - eg masto.canadiancivil.com in your case - then we know the instance admin(s) have done it, which is good enough auth. Sadly this isn't a priority for me right now, but when I do get to it, I'd probably try it out manually with a few admins like you by hard-coding the domain template for your instance, eg |
|
I was thinking about this more, and I like @shiribailem's idea of reverse proxying I'd probably also start with only supporting Given all that, I think the only thing instance admins would need to do is set up the redirect. Bridgy Fed could serve those redirects automatically, for all users, without me needing to turn it on per instance. |
@snarfed Would this require instances to have a wildcard SSL certificate on their domain? With services like LetsEncrypt having a wildcard certificate is only possible through DNS1. personally I find DNS1 quite annoying to setup and sometimes not always feasible. wildcard certificate aside, I do think from a users standpoint just reverse proxying is probably the easiest way to set this up. |
|
By the way, I still think having a simple TXT record on your domain that bridgy can check would be a really simple and clean solution to make this possible. instance:
This way, it's up to the instance owner to setup the way they want to have their users DID verified. this would enable both HTTPS and DNS verification to work. |
Yes, there are two ways to verify, either from a TXT record in your DNS which requires a separate record for every single user, or a wildcard to an HTTPS page that can verify DIDs. This discussion is around making it an automated process as much as possible and the HTTPS verification method is absolutely the fastest. If you wanted to go the other route you could potentially pull your list of usernames and auto-generate the TXT entries by polling bridgy. This also leans into another conversation around handles, because those HTTPS base pages can be used to send requests to the bluesky profile page (many if not most users don't actually search for usernames, they either click the link or put it in their address bar... so it'd be helpful to people to just redirect them to profile)
Nothing really changes in the implementation on the bridge side there, I'd prefer to encourage proxying just to reduce load on bridgy by being able to cache those results, it's not like the DID changes often? |
Yes! They'd definitely need a wildcard SSL cert, regardless of whether they reverse proxy or redirect the And these requests will be relatively cheap and easy to cache for BF, so I'd probably lean toward redirects because they'll almost always be simpler for admins, but we can see. |
|
Some problems I see with Wildcard certificates is that with letsencrypt you need to use DNS1 verification which requires access to your DNS. So if you're using managed hosting, chances are your hosting provider doesn't have access to your DNS. I think its safe to assume almost everyone uses letsencrypt at this point? In most cases you need to setup some system that will automate the DNS verification for you via an API provided by your DNS provider. Not all providers have an API and or your provider might not be supported by whatever method you use to manage your certificates. OWASP also cautions agaisnt the use of Wildcard Certificates: Here . I think you ( @snarfed ) initially ran into issues with generating certificates at scale for everyone bridging
I'd really like to know if there are problems with what I'm proposing above? It could easily be implemented along with supporting a redirect on This way, if the TXT record says the domain should be |
|
Hey @S0yKaf, yes! Sorry for not responding earlier. I appreciate all the info, research, and ideas! So, there are two questions here: 1) how to do ATProto handle resolution, and 2) how to let instance admins specify a custom format for handles. Wildcard certs are for 1; your DNS proposal is for 2. You're absolutely right that wildcard cert verification will generallly need DNS access. The other way to do ATProto handle resolution is DNS-based, which...also needs DNS access. So if instance admins want custom Bluesky handles, they're going to need DNS access. And you're also right that I did look at all of this for Bridgy Fed itself. The catch is that our default bridged handles are multi-level, not flat under ap.brid.gy, and you can't do multi-level wildcard DNS records or SSL certs, so I picked DNS because it was much easier to automate. Background: #744, #830 Re 2, custom handle format per instance, your DNS proposal seems good! I don't know if I'd tackle the additional complexity at the beginning, I'll probably start with a fixed format, either the same for all instances or maybe keeping a lookup table per instance that I update by hand, but if/when I want to automate, I'll definitely keep it in mind. |
|
Hey, So I've been thinking about this more. The reverse proxying of I think what I've really been trying to say is that It would be nice if along with adding some mechanism that automatically checks if you're proxying
The reasoning for this is the same conclusion as you. It's a lot easier to automate DNS than to setup a whole SSL certification pipeline. Specially if you control your nameserver directly. Plus it just makes it so bridgy supports both ways of resolving an ATproto handle. It might not be immediately obvious how it would be easier for someone to verify their handle in such a way but my feeling is a lot more people will come to choose this route as ATproto matures. EDIT:Just to clarify, in the situation where you don't control a domain directly, you can ask the owners to create a |
Understood! And agreed, it's generally easier to automate DNS than SSL cert renewal. However, the missing piece is that the fedi instance admin then needs to get each of their users' bridged DIDs from Bridgy Fed before they can put them into a DNS record, and they have to keep doing that, ongoing, as new users sign up and get bridged. That's nontrivial custom code and automation. If they just redirect (or proxy) |
|
Are you fundamentally against the idea of supporting both ATProto identification schemes? If someone were to open a pull request adding my proposed DNS verification mechanism, would it be a welcome addition? |
|
I'm not fundamentally against supporting both. I'm just scoping the work that each one would take, and prioritizing based on that. DNS seems like substantially more work, on both sides. (I know you're aware, the custom nameserver patch you wrote that populates these records based on Bridgy Fed's own DNS sounds awesome!) It's also somewhat academic right now; I'm waiting to make any decisions or design too specifically until I start hearing from medium or large instance admins who are ready and willing to actually do this. (I love small instances!...but if your instance only has a few users, this is overkill, you and your users can just set your handles manually.) |
|
Here's my thought on those aspects: I think the page for the /.well-known/atproto-did is a minimum for all solutions. For the DNS version that same endpoint is what you would use for such a script to collect the DID as well. HTTPS sounds like it's extra, but it's honestly imo the simplest approach in reality. For one it requires no custom tools on the instance admin's end, everything is well established stock materials. Additionally, it's completely passive, you set it up and it's not doing any continual api calls or anything, it doesn't even need to know what users are available. DNS version requires a bunch of structural elements, namely it requires an API call from the instance to the DNS for every single user account. Worse yet it needs to know to make this request so it'll have to be either prompted by Bridgy Fed or it'll have to integrate with the AP instance itself to get the current users. And all of that is before hitting the limits from the DNS provider. Not saying don't do that option, just saying that pretty much all the work for HTTPS contributes to it as well and it'll be a separate project on top of that one. The bare minimum of the HTTPS version is just setting the well-known endpoint, everything else is extra friendliness. |
serves ATProto handle resolution for fediverse instances and others who want to redirect their domain's /.well-known/atproto-did to us. takes a host parameter, unlike normal handle resolution which passes no params. fedi instances can set up wildcard DNS and SSL cert on their instance, redirect all subdomains to fed.brid.gy/.well-known/atproto-did?host=... , and automatically get custom Bluesky domain handles. #1537 https://atproto.com/specs/handle#handle-resolution
Got an interesting request today: a fediverse instance would like to give all of their users who enable the bridge a custom domain handle on their instance's domain, eg @[email protected] would get the username user.insta.nce on their bridged Bluesky account.
Doable! It'd take some work though, and some custom development on the instance's end. Notably, they'd have to get each user's DID from Bridgy Fed and either put it into the corresponding DNS record or serve it over HTTPS on that custom domain.
Related: #1305
The text was updated successfully, but these errors were encountered: