Supporting multiple domains on a single instance

[wxcafe]

It would be great to be able to just point multiple domains at one instance and have all users on that instance be able to be addressed with all these domain names. With email, for example, if I have two
domains pointed at my servers, it will be able to answer for emails for both domains (it's a bit more complicated than that for email because of the MX records but the basic idea is the same). I only have one unix account on the server, but I receive mail for two addresses.

---

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

[DeadSuperHero]

Could you clarify what the use case is that you're going for?

It sounds like you want to have multiple domain name aliases for your Mastodon account, of which users could mention either wxcafe@domain1 or wxcafe@domain2, and you would essentially be referencing the same account with the same posts.

My question is, why might you want this?

In terms of multi-domain federation, the most common use case I've seen (in Hubzilla, no less) has been that of a relay system that chains two or more accounts together on different instances, running on separate domains. Each relay receives notifications and interactions for itself and connected accounts, and posting from one account recreates the exact same post on each subsequent clone account. Additionally, you can log in to each clone in case your main server ever goes down.

[wxcafe]

I'm guessing the use case is to have aliases to your address, like you can with email, without having to put up a new, completely different instance. Like, I can have wxcafe@serious.domain for professional emails, and wxcafe@toot.suite for, uh, more relaxed conversations. I also just think it would be more intuitive to admins if it worked that way.

…

-- Clément 'wxcafé' Hertling

On Fri, 2017-04-07 at 18:11 -0700, Sean Tilley wrote: Could you clarify what the use case is that you're going for? It sounds like you want to have multiple domain name aliases for your Mastodon account, of which users could mention either ***@***.*** or ***@***.***, and you would essentially be referencing the same account with the same posts. My question is, why might you want this? In terms of multi-domain federation, the most common use case I've seen (in Hubzilla, no less) has been that of a relay system that chains two or more accounts together on different instances, running on separate domains. Each relay receives notifications and interactions for itself and connected accounts, and posting from one account recreates the exact same post on each subsequent clone account. Additionally, you can log in to each clone in case your main server ever goes down. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[davidak]

You could have multiple domains for new users to choose from like cock.li or GMX.

Another feature would be to have multiple accounts connected to switch between like described in #1405

But please don't let users of such instance simply have adresses on multiple domains. That would confuse new users totally!

[BjarniRunar]

I would like to chime in here; this feature can be very important for helping users "own" their identities and for making it possible for a user to migrate from one instance to another. I strongly recommend it be implemented with that in mind.

If I understand correctly, OStatus subscription mappings are based on the user's handle, user@mastodon.foo. This means it's hard for the user to migrate because the name of the instance they signed up on is recorded in the settings of all their followers. If the handle was instead user@usersdomain.com (or even user@user.mastodon.foo if the owner of mastodon.foo is willing to give away subdomains), changing the DNS for that record to point to a new instance (plus copying the data over) would solve migration quite elegantly.

The most basic implementation of this would probably involve letting the user specify in their settings a domain they would like to use in their public handle, and then using that when generating URLs. That might be all it takes, it then becomes the user's problem to buy a domain and set up a CNAME correctly...

[ed-davies]

I agree with Bjarni here; it'd be better if users could use their own domains in much the way they commonly use their own domains with shared email servers. A concrete example:

I own edavies.me.uk. The MX record for that domain currently points to the mail server for the hosting provider I use (mx.mythic-beasts.com). I can move to another hosting provider just by updating that MX record - nobody needs to change the email address they use to talk to me.

Similarly I'd like to be able to point some DNS record at the Mastodon server I currently use (octodon.social). Perhaps rather than a new record type a SRV record would be better. Maybe:

_mastodon._tcp.edavies.me.uk SRV …

Would have to re-read how SRV records work to be sure about this. Also, not sure if the _mastodon bit is over specific. Maybe _social._tcp.mastodon.edavies.me.uk.

I don't think a CNAME alone would cut it as I'd want ed@edavies.me.uk (or ed@mastodon.edavies.me.uk) to map to my edavies@octodon.social account. In other words, the user name part of the public URL needs to be included in the mapping in case it's different from the account name on the social media server. I might want to move to mastodon.xyz at some point after somebody has already taken the edavies user name there and I need to be edavies99 or something.

[BjarniRunar]

If you go with a SRV record, then all the tools need to be updated - including web browsers I think! If you use a CNAME or an A, then everything just works, at the cost of requiring you use a subdomain. I'd go with "ugly but works" over "elegant but will never get deployed in our lifetime". But maybe I'm overstating the problem.

Your mapping concern can be solved in the software implementation; one trivial solution is that if a user provides their own domain then you can simply ignore the username@ part.

[ed-davies]

Yes, for a URL like https://mastodon.edavies.me.uk/@edavies CNAME is the only plausible approach (which doesn't work the HTTPS, anyway, though it does work with HTTP and redirects to HTTPS along the way: http://mastodon.edavies.me.uk/@edavies).

For @edavies@mastodon.edavies.me.uk mapping to @edavies@octodon.social within the social network (e.g., in a follow list) the use of some sort of SRV record or the like is much more plausible for deployment in our lifetime, or even in our teatime, but maybe somebody more familiar with the insides of this social network stuff could say more.

There's currently no standard way of dealing with such a thing in browsers, etc. The closest is that the RFC for acct: URIs (RFC7565) gives use of webfinger as an example use but, perhaps unfortunately, doesn't mandate it or any other lookup method; these URIs are URNs rather than URLs.

[ZiiX]

Second what @davidak mentioned, @BjarniRunar & @ed-davies.

Allowing a user to chose from any available domains my instance owns as well as allowing them to point their own domain to my server/instance, me do a manual/admin handshake to approve it, and then them sign up accordingly on my sign-up page. I'm for this. I own my own @email and can take that with me to different providers - it's my identity.

[SoniEx2]

What about bridging icann and opennic?

[Gargron]

Duplicate of more technically specific #2668

[erinarbleizez]

I'm now confronted with another reason for this feature:

I want my instance to be available on both the clearnet AND with a .onion on tor. It seems that right now it's not possible and I have to choose...

As a social network visibility through clearnet is important but privacy concerns for a lot's of people that did the migration to mastodon should be taken seriously and we should not force them to use an exit node or the clearnet if they don't want to...

[nightpool]

@erinarbleizez Making an instance visible from two domains currently is not a problem, as far as I know. The issue is that only one of those domains counts as "valid" as far as webfinger/push/salmon requests goes.

Users should still be able to access the server from a secondary domain, but other servers will only recognize your clearnet domain as the correct address for accounts. I think that matches your usecase just fine though.

[SoniEx2]

Unless they wanna be visible to tor-only instances.