Mastodon: Subdomains

[tomitm]

I haven't gotten to running my own instance yet (soon!), but I'm seeing a lot of @[email protected] in toots, instead of @[email protected].

With email, you can host a server and access your mail at mail.example.com but still address to [email protected] thanks to MX DNS records. Users get a simple email address, and the servers figure out the rest.

If you have to use a subdomain because you already have something else on at example.com, it seems like you end up having to use [email protected] as your username instead, unless you create a new domain, like example.social.

It looks like there's a LOCAL_DOMAIN variable, but I haven't seen anything akin to email's MX record. I can't find much documentation on LOCAL_DOMAIN. I'm not sure if this is already there, but hasn't been fully documented/communicated yet, or this just hasn't happened yet.

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[tomitm]

Actually, I think I'm focusing on email/DNS too closely here... I didn't notice WebFinger seems to serve the role of account resolution (I think?). 🤔

Can WebFinger alias example.com to mastodon.example.com while keeping the subdomain transparent to the user?

[JantsoP]

Just set the LOCAL_DOMAIN as an sub-domain, make an A record to your DNS and follow the MX creation instructions for your SMTP provider (MailGun etc.) After that, remember to mark the servername in nginx as the same sub-domain as you set in LOCAL_DOMAIN

[tomitm]

As far as I can tell, your full address is @username@LOCAL_DOMAIN, so setting LOCAL_DOMAIN to your subdomain isn't what I'm after. Did I misunderstand this?

I'm suspecting setting LOCAL_DOMAIN to example.com and only serving Mastodon requests at mastodon.example.com wouldn't work right now, unless WebFinger was available at example.com/.well-known/ to point the federated servers to the correct subdomain.

[plinss]

In other systems, like XMPP and Matrix, this is achieved by using a SRV record, for example you can have an XMPP address of "[email protected]" and your XMPP server at im.example.com by setting the SRV record:
_xmpp-server._tcp.example.com 0 5 5269 im.example.com.

Note this also has the advantage of specifying the port number (5269 in the above example) as well as load balancing (by using multiple SRV records) and neither the port, nor the actual name of the server, need to appear in the user's address.

[lilyball]

I would really love to see support for this. More generally, I want to be able to use my email address as my Mastodon username, but of course my email's domain already has a website hosted there.

[ineffyble]

Unfortunately, Mastodon strives to be compatible with the OStatus set of protocols, and to my knowledge they don't support this type of flexibility.

[ThibG]

I'd have to read OStatus, but wouldn't Mastodon just need to use a base URL for its APIs and assets that is independent of the domain it serves? (this domain would still have to serve the webfinger requests)

I'm looking into that, but can't find how account_url, api_salmon_url etc. are defined in Mastodon

[Gargron]

I agree that it should be possible to do this by proxying /.well-known to Mastodon from the root domain. However currently the code expects all URLs to come from the definition of LOCAL_DOMAIN, i.e. that's for both "what do I consider to be my own domain identifier wrt. federation" and "how to generate absolute URLs for links". For the subdomain/domain split to work, these two functions need to be split, Mastodon must think that the root domain is its identifier wrt. federation, but use the subdomain to generate any URLs.

[plinss]

@ineffyble Understood, I wasn't proposing that Mastodon break with OStatus, but rather that we lead an effort to add SRV support to OStatus, perhaps with Mastodon as an initial, experimental implementation.

@Gargron proxying webfinger from the base domain would be a reasonable first step, and would likely solve most uses (and be much appreciated), but can collide with other webfinger services.

[Shnoulle]

I'm not sure mastodon or gnusocial must 'hack' the final user name, but maybe.

But doing the webfinger on another domain seems really another part : it's the base domain to do it. Give some ruby code (or python or php) .

I explain :

1. I set [email protected] in webfinger of example.org
2. Set it to [email protected]
3. A mastodon user can connect to me with [email protected]
4. I'm tired of mastodon, and then want to move to postactiv
5. I update my webfinger to go to [email protected]
   => It's great if other mastodon instance follow me to my new 'me', but old notice/toot still only on mastodon.example.org and not on postactiv.example.net (except if i use a tool to move all notice/toot : and this tool didn't exist currently).

The only needed part is: allow in some condition update final user with his webfinger. I my opinion.

[lilyball]

FWIW, I think a SRV record is a far better approach than proxying WebFinger from the root domain to the subdomain. The reason being, Mastodon uses WebFinger, but other things could too, and proxying WebFinger means acct:[email protected] is always going to be treated as a Mastadon user even if example.com hosts other services that use WebFinger. Whereas with a SRV record, Mastadon would then send WebFinger specifically to the Mastadon instance instead of to the root domain.

[tomitm]

@kballard I read through the WebFinger spec earlier and I don't actually think that will be a problem.

The subject isn't the relevant part of the response, it's actually the rel links. Also note that the spec allows you to filter the response by rel.

As for hosting multiple services on the same domain, I don't believe that concerns Mastodon. That's up to the service you're using to proxy/serve Mastodon's WebFinger requests at the root domain to aggregate the responses from all services.

[ThibG]

While working on a patch to add this feature, I stumbled on something: it is not clear how Mastodon should handle other instances where the domain name and web front-end URLs are different.

Indeed, if I understand OStatus correctly, users are identified by URIs that do not need to be of the form [email protected]. Furthermore, in toots, users are mentioned with links with their public web profile, which in our case would be https://social.example.org/users/user. This page in turn links to the ATOM feed https://somedomain.org/somepath.atom, which is fetched by Mastodon if an user it doesn't know was referenced. In this case, it assumes the identifier is [email protected] where author is the value of node at path //xmlns:author/xmlns:name.

This is not an issue for accounts known to the Mastodon instance before the mention, as it will search for known users with the same profile URL, but this is problematic for otherwise unknown accounts. Since OStatus doesn't use the user@domain identifier scheme, this is not completely obvious to me how to fix, but I guess Mastodon could try to webfinger on //xmlns:author/xmlns:email, which is the Mastodon user identifier in case of Mastodon instances.

[Gargron]

Remote accounts store uri as-is, regardless whether it's of the form that looks like an e-mail, like a URL, or maybe a random UUID. But the main schema is based around the concept of "usernames" on "domains", and this is rooted in Webfinger - you ask Webfinger at the domain whether a username on it exists, and it answers. Then Webfinger links to feeds, profile URLs, etc - that is all secondary.

[Gargron]

@kballard @tomitm Indeed, if you wanted you could make your own Webfinger endpoint linking to all services you want, you'd just have to link to the ones from Mastodon manually somehow or by proxying parts of the response.

[ThibG]

@Gargron indeed, but an account won't be added unless discovered via Webfinger, and mentions to unknown profile pages will use the atom feed's URL to discover the domain used to query Webfinger. I think using the value of the “email” node if it exists might be a better way to do it.

[lilyball]

This doesn't seem to actually work yet. Webfinger is returning the regular domain instead of the web domain in 2 of the URLs. See #2375 for details.