Frequently Asked Questions

Spaces are rooms and can be deleted in the same way using the delete room Synapse Admin API.

Set the following settings:

• Security & Privacy -> Encryption -> Encrypted: Off ¹
• Security & Privacy -> Access: Public
• Security & Privacy -> Access -> Show advanced -> Enable guest access: On
• Security & Privacy -> Who can read history: Anyone

Guest users only work if a native user on the default homeserver configured in your client is a member of the room. For example, to join a room on your EMS server as a guest using the client at https://app.element.io/, an account on the matrix.org homeserver must be a member of the room.

¹ Guest users will technically work with encryption enabled, but guests will not be able to read any messages as they do not have the keys to decrypt them.

It's not recommended to add encryption to public rooms. Anyone can find and join public rooms, so anyone can read messages in them. You'll get none of the benefits of encryption, and you won't be able to turn it off later. Encrypting messages in a public room will make receiving and sending messages slower.

Spaces are just rooms, so you can link to a space the same way you would a room—for example, https://matrix.to/#/#community:matrix.org.

In a room with more than two members, voice and video calls are done using the Jitsi integration. Users need "Modify widgets" permissions to add the Jitsi widget to the room and initiate a call.

Once the call is initiated, anyone in the room can join.

Room and space icons can be shown in a full-screen lightbox, so the resolution should be high. The homeserver will create a smaller thumbnail that is displayed when viewing rooms and spaces normally.

If you have multiple Matrix accounts - for example, an EMS account and a matrix.org account - you cannot log in to both simultaneously in the Element Desktop client today. However, you can launch multiple Element instances locally via its Profiles feature.

Your Matrix username/localpart can only contain lower case letters, numbers, and the characters . _ = - /.

The best response to 'What is an Identity Server' is detailed in section 2. of the vector.im Identity Server privacy policy, available here: https://element.io/is-privacy-notice.

New Vector runs two identity servers, one at matrix.org and another at vector.im. These servers run in a closed federation - this means that if you add (or remove) your data from one, it is added to (or removed from) the other automatically, too.

The behavior and role of Identity Servers are changing. Historically, Identity Servers provided three sets of functionality:

1. They let users publish their third-party identifiers (email/telephone number) to a directory to allow other Matrix users to discover them.
2. Letting users send invites to a Matrix chat room to an email address instead of a Matrix ID.
3. Letting homeservers send emails/SMS text messages to verify that they belong to a given Matrix user so that the user can log in to the homeserver using a third-party identifier instead of a Matrix ID.

Identity Servers continue to provide the functionality described in 1. However, the features described in 2. and 3. are now provided by the homeserver instead and will be deprecated and phased out of the Identity Server in the future.

For a period in 2019, while privacy functionality was being enhanced on vector.im and matrix.org, these Identity Servers were restricted to only provide services for users on New Vector homeservers. Once privacy improvements landed, this restriction was lifted.

It is best if EMS customers delete their host or account themselves. Here's how:

Delete the host from the host management page at https://ems.element.io/user/hosting by clicking the Delete host button (and confirming deletion in the resulting dialog). This will delete the host and cancel all associated subscriptions.

Or delete the EMS account entirely. This is done from the user account page https://ems.element.io/user/account by clicking on the Delete account button and confirming. This will delete all hosts and subscriptions before removing the user's account.

Bots allow you to get information and perform actions in line with your chat. There are a bunch that can be found at https://matrix.org/docs/projects/bots/.

Unfortunately, you are not currently able to host your own bridges to work with your EMS-hosted homeserver. As of December 2020, we have added a Telegram bridge to EMS. See our blog post: EMS brings more interoperability to messaging.

If you have federation enabled for your homeserver, you can also bridge into publicly accessible rooms, such as https://t2bot.io/, or integrations available on public homeservers such as matrix.org.

Yes, but we're currently reviewing the bridging pricing models, and soon we'll likely be offering Slack (as well as all of our other bridges) on a usage basis rather than on a room/workspace capped basis.

When this launches, existing customers will be able to stay on their existing plan or choose to move to the new model.

To create a GitHub integration in a room, click on the i icon at the top right, accept the privacy policy, click Add widgets, bridges & bots, click Add integrations and select GitHub from the Bots list. When prompted, log in to GitHub and select the repositories and functions you want.

Note that your server needs to have federation enabled for integrations to work.

To create RSS integration in a room, click on the i icon at the top right, accept the privacy policy, click Add widgets, bridges & bots, click Add integrations and select RSS Bot from the Bots list. Then, enter the RSS URL and click Subscribe.

Note that your server needs to have federation enabled for integrations to work.

Please talk to your account manager, or open a support ticket by emailing support@matrix.org. The bridge team will consider requests on a case-by-case basis.

They're mostly the same. The big difference is that the free one doesn't bridge DMs / puppet your account. See also Do DMs count towards the 20 channel limit for the paid Slack bridge?

Jitsi conferencing data goes directly from the browser to the Jitsi server, and it does not use the Matrix protocol. If you add a Jitsi widget to a room, that widget will be stored in the room state as Matrix events, but the Jitsi communication itself is from the client to the Jitsi server used.

Messages are stored on your server. However, if you are communicating with users registered on other servers, then relevant messages/events will also exist on their server.

The file upload limit for EMS hosts is currently set at 100MB.

The web console has a form to do this. "System status messages" - You can use this form to send messages to all users of your server. For example, this could be used to send "messages of the day", or important policy updates, etc.

EMS aims to take the hassle out of hosting and managing your own Matrix stack. There is a significant technical overhead (in terms of technical knowledge required) as well as ongoing time and resources to ensure that your server continues running and is kept up to date with all of the latest security updates etc. With EMS, you don't have to worry about that, as it is all taken care of for you at the touch of a button.

We also provide a (growing) suite of proprietary host administration tools in the form of the EMS Synapse admin dashboard to help give you better insight and control of your server.

We’ve shied away from hard limits for storage and instead adopted a fair use policy. If you use the server for business conversations and share a few images as part of your discussions, you will never have problems. However, if you share thousands of images daily per user, you will hit a limit.

Currently, we only accept Credit or Debit/bank account cards as payment. "Debit cards" should work with any regular bank account.

To update your payment info, go to https://ems.element.io/user/billing. From here, you can update your payment details.

No, you are only ever charged for users that are registered on your server and who have been active for more than two days in a month. These users make up your Monthly Active User (MAU) total. Users that are registered on other servers (that you communicate with over federation), guest users, and users who are only briefly active on your server are not counted.

Uploading custom (YAML) registration files for appservices is not currently supported for EMS hosts.

We are actively working on improving bridging support for EMS hosts and hope that this will be something that you see substantial improvement in over the coming months.

Yes, absolutely! However, you need to set this at host creation time as the homeserver name is "baked in" to all of the events that the homeserver creates.

You can set both the homeserver name, e.g., example.com (so your Matrix user IDs would be of the form @foo:example.com), and your (Element) client address, which might be something like webchat.example.com. However, to prove that you own the domain in question, you will need to place some JSON / text into two well-known files on the webserver for your domain. In the setup wizard, you will be guided through this process when setting up the custom domain for your server.

Yes, this is available for Gold and Enterprise customers. Please talk to your Account Manager or open a support ticket.

This is currently not possible, unfortunately.

Yes, you can modify the look and feel of your client to suit you.

Please see our blog article on custom branding for your Element instance here https://element.io/blog/custom-branding/ and Client Look & Feel for more details.

You will be able to enter the customization preferences from the managed host page of your EMS account - https://ems.element.io/user/hosting.

Yes. However, this is not recommended. For the same reason your email address probably is not someone@email.example.com, you probably don't want your Matrix IDs to be @someone:matrix.example.com.

Please see https://matrix-org.github.io/synapse/latest/setup/installation.html#choosing-your-server-name for additional details on your server name.

Yes, you can, but there are some limitations:

• You will not be able to serve a website on the domain.
• Using a CNAME DNS record on the root of a domain is not compliant with the DNS Specification (per Domain Name System RFC 1034, paragraph 3.6.2 specifically). But you may still be able to do this successfully if:
  • Your DNS provider allows setting a CNAME record on the root of your domain. Be aware that certain other DNS records for your domain will not be returned properly, including SOA, NS, and TXT records. (Such as SPF, DMARC, and DKIM, which are used for securing email), OR
  • Your DNS provider offers a DNS Spec compliant workaround for using CNAME on root. This includes ALIAS records and CloudFlare CNAME Flattening (note that proxy must be turned off).
    • When using this, please note that the EMS Control Panel will not recognize your DNS record as correct, but your EMS server will function correctly and without limitations (beyond the yellow warning in the EMS Control Panel)
• If your DNS provider does not allow CNAME records on root or a DNS Spec compliant solution like ALIAS records, you can use an A record instead. To do this, finish setting up your EMS server without adding the DNS record when asked. After setup is complete, check the IP address of your EMS server, for example, with $ dig example.ems.host in the Mac/Linux terminal or Resolve-DnsName -Name example.ems.host in Windows PowerShell, then add an A record on the root of your domain pointing to this IP address.
  • Please note that EMS does not officially support this, and we reserve the right to change the IP address of your EMS server without notice.
  • You will see the same error in the EMS Control Panel as above, but your EMS server will work with this configuration.
• Using a subdomain for your EMS server. By doing this, you will not see any of the limitations and do not need any of the workarounds listed above. However, please consider Can I use a subdomain instead of the root domain with my EMS server?

• You need to create a CNAME record with your DNS provider. This needs to be: chat.example.com. CNAME yourEMShost.element.io. (please note that proxy must be turned off if you are using CloudFlare)
• You need to set up a website on your domain, e.g., example.com.
• This website needs HTTPS enabled.
• You need to create two files on the webserver. These need to be located at exactly:
  • https://example.com/.well-known/matrix/client
  • https://example.com/.well-known/matrix/server
• You need to enable the CORS header Access-Control-Allow-Origin: * on the webserver for the client file. See https://enable-cors.org/ for instructions on how to do this.

The client file needs to contain:

{
    "m.homeserver": {
        "base_url": "https://yourEMShost.ems.host"
    },
    "m.identity_server": {
        "base_url": "https://vector.im"
    }
}

The server file needs to contain:

{
    "m.server": "yourEMShost.ems.host:443"
}

You can use the CNAME with CloudFlare, but you have to change the Proxy status to DNS only.

If you have federation turned on in your server configuration, you are able to communicate with users registered on other servers (e.g., matrix.org).

You are only ever charged for users that are registered on your server and who have been active for more than two days in a month. These users make up your Monthly Active User (MAU) total. Users that are registered on other servers (that you communicate with over federation), guest users, and users who are only briefly active on your server are not counted.

This problem is most likely caused by a delay in DNS replication downstream of your DNS servers.

You can gain admin permissions in this room by calling this Synapse Admin API or by contacting EMS Support at https://ems.element.io/support.

Gold and Enterprise customers can also request changes to the list of default rooms their users are automatically added to.

You can rename the Element client from Element to for example Company Chat with the Client name field on https://ems.element.io/user/hosting#/hosts. See Client Look & Feel for additional details.

You can only set a custom domain name for a server at setup time. This is because the server's domain name is "baked-in" to all of the events generated by the server.

So, you would need to deprovision an existing server and create a new one, selecting your custom DNS preferences from the advanced settings section of host setup configuration if you wish to change the current host DNS.

You can deactivate users from the admin dashboard for your host at https://ems.element.io/user/hosting.

Select the Server Admin tab and then the User Info sub-tab. From here, you can search for the relevant user and hit the Deactivate account button.

The public room directory is enabled on your EMS server if both Federation and Guest users are enabled.

Currently, the process of migrating away is manual. However, we hope to have an automated, self-serve system in the not too distant future. For the time being, if you wish to migrate away, please email ems-support@element.io (while your EMS server is still up and running) and ask for a snapshot of your Synapse database. We will then generate a snapshot for you and create a link to download the data. You can then use this to restore the database / Synapse instance on your own infrastructure.

Note that migrating from EMS to self-hosted is only possible if you use your own domain (Custom DNS) with your EMS server.

This is part of a security measure. We generally prevent hosts from returning to the pool after they were initially claimed to prevent people from attempting to imitate old servers/users. Contact support from https://ems.element.io/support while signed in to get the hostname released.

Unfortunately, we are not able to offer user presence as a feature at the moment. This is due to potential performance impact and excess resource usage on hosts when this feature is enabled. The Synapse team is aware of this, and it is on their roadmap to address. However, we do not currently have a timeline for when it will be available again.

When you bridge to external services, external users get an "appservice user" on your EMS server. If you have any bridges and check this checkbox, users from across your bridges will also be shown.