So.... what domains should we use for our matrix server?

I like too :slight_smile:

1 Like

+1 for, provided the domain is already controlled by Fedora Infrastructure / Red Hat.

It is worth noting Fedora contributors already have a mailing address alias with their FAS usernames. If a contributor wished to use the domain to represent themselves, they could still do so (and have). I like for Matrix because it is short, succinct, and easy to type.

It is subtle, but a short domain is best because it will be typed frequently, as many Matrix users know. :sweat_smile:

1 Like

I kind of prefer to

  • It seems less formal, which may be a good thing if people are going to use it for informal not-Fedora related things where might feel awkward. I think this is more important due to Matrix clients mostly not supporting multiple accounts.
  • It’s shorter. It probably has no effect on Matrix itself, but it may mean (a bit less) traffic to bridged protocols like IRC where the username is generally shown in real name (gecos) and it can be cut with particularly long account names. The real name may matter in case of channel access or bans which in case of freenode has extban $r for bans and quiets (I thought also invites, but the /quote help extban integrated documentation of freenode disagrees.
  • Anyone using it can add #whatever:domain.tld aliases for rooms and any room moderator can publish those. That may result into nasty addresses involving Fedora Project circulating around. I originally had some other reason here, but it slipped my mind and I was only able to think this in addition to the two above ones.

I also saw a question on Fedora Diversity brought up on whether Matrix accounts will be renameable once FAS/Noggin supports that, but that may be a topic for different thread.


I’m +1 to I don’t use and don’t see why to use fp.o outside the project. sounds more like a chat client or something like that


+1 for
It feels more official and has a more obvious affiliation to the project it is for. Not that is bad, but I could see that causing more of the already common misunderstanding around a specific headwear :wink:

And this ^

1 Like

What about Like

But, is less formal and shorter.

For the reasons pointed by puiterwijk.

I’d personally prefer The symmetry with email addresses makes it easy for me to remember and the rest of the larger community understands as someone from the Fedora community. We’ve been doing it for a long time with the email address. Additionally, I actually expected that we’d gate an account on the server on CLA+1 like we do getting the email alias.

Note that you wouldn’t need a Fedora homeserver login to access Fedora Matrix rooms anyway.

I kind of wish we could have both though. I get the benefits of and it’s certainly trendy and cool! :wink:

Is there a way where we could issue either one or both?

And also note that whatever the primary domain for the Matrix server is set to, that’s what all the Matrix rooms would use too. I want, not


The domain has already been taken

1 Like

Right — we own


+1 on domain

Its simple, shorter and it’s more directed to the intuite of usage.

I like Neal’s idea of having both, with name ruled by the same policy as the fedoraproject mail alias, while being relaxed version.

It would feel much more natural for me to use a “traditional” handle.

But if it is hard to implement now, then Patrick’s point on not requiring the Contributor agreement for wins the argument for me.


I think it is already possible for people to have links/tags that show after their FAS account without CLA+1. It is probably a fluke, but I don’t think I have the “+1” and yet the link on my Fedora Magazine comments has always showed That might be because I misconfigured something when I created the WordPress account, but nevertheless, I think it has always been possible to have such “ids” without CLA+1. So maybe that isn’t too serious of a concern?

Here is a link to an example comment on Fedora Magazine with my name connected to

(Update: I asked an in #element-web and it doesn’t seem like my concern was warranted). Using a different subdomain is apparently fine.

Element themselves recommend using a different domain for the homeserver and for Element. Using a different subdomain ( and wouldn’t solve this issue as it’s still the same domain.

It isn’t necessarily a big risk, but using a different domain completely eliminates that attack vector. It’s probably best to be extra cautious. So my vote is for

We do not recommend running Element from the same domain name as your Matrix homeserver. The reason is the risk of XSS (cross-site-scripting) vulnerabilities that could occur if someone caused Element to load and render malicious user generated content from a Matrix API which then had trusted access to Element (or other apps) due to sharing the same domain.

We have put some coarse mitigations into place to try to protect against this situation, but it’s still not good practice to do it in the first place. See GitHub issue for more details.


Server on, self-hosted Element Web on

Accounts looks better and more official, IMO.


To clarify: → your openid identity. Everyone with a account can have one. alias → an email alias that forwards to your email in account system. Only folks with fpca+1 group have these.

OpenID identities are slowly going away. Only a few things use them in our infra anymore (magazine, pagure, bodhi, badges).

1 Like

TLD for the Isle of Man? This is really better than buying

They are not the same domain. There is (was) a feature that allowed a superdomain to access a subdomain, but it requires code (deprecated code) on both sides to work:

Excerpted from Same Origin Policy - Changing Origin:

The approach described here (using the document.domain setter) is deprecated because it undermines the security protections provided by the same origin policy, and complicates the origin model in browsers, leading to interoperability problems and security bugs.

Note: When using document.domain to allow a subdomain to access its parent, you need to set document.domain to the same value in both the parent domain and the subdomain. This is necessary even if doing so is setting the parent domain back to its original value. Failure to do this may result in permission errors.

1 Like has my vote as well. Keeps things consistent. would be cool for a future Jitsi meet server. :slight_smile:


Update: my concern doesn’t seem to have been warranted. Using a different subdomain for Element and the homeserver is fine.

At least the way Element has written it, I believe that using one root domain for both Element and the homeserver has the potential for risk.
However, perhaps my interpretation is wrong or the Element info is outdated. It’s possible that the documentation you linked indeed disproves my interpretation (I’m not sure myself).

We do not recommend running Element from the same domain name as your Matrix homeserver.

To me “domain name” refers solely to the root domain, in this case This would mean that using for Element and for the homeserver is not recommended.
If “domain name” refers to the subdomain, that means using and is recommended by Element.

As I said before it’s possible there is no risk to Element today, but considering there seems to have been some risk in the past, it seems reasonable to me to be extra cautious.

I do believe there are general risks with using one root domain for a mix of user generated and static content. For example, GitHub stores user generated content under different root domains (e.g. instead of putting it on subdomains of GitHub made that change 7 years ago though, so perhaps there is zero way of there being issues like that today.

It would helpful perhaps if we had official word from Element on what there recommendation is today. Especially since they’re the ones who will be hosting Fedora’s Matrix instance.

1 Like