To completely disable federation, isolating your server from the rest of the Matrix network, add this to your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
To completely disable federation, isolating your server from the rest of the Matrix network, add this to your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
@ -72,6 +72,21 @@ To use a more custom configuration, you can define a `matrix_ma1sd_configuration
and put your configuration in it.
and put your configuration in it.
To learn more about how to do this, refer to the information about `matrix_ma1sd_configuration_extension_yaml` in the [default variables file](../roles/matrix-ma1sd/defaults/main.yml) of the ma1sd component.
To learn more about how to do this, refer to the information about `matrix_ma1sd_configuration_extension_yaml` in the [default variables file](../roles/matrix-ma1sd/defaults/main.yml) of the ma1sd component.
## Example: SMS verification
If your use case requires mobile verification, it is quite simple to integrate ma1sd with [Twilio](https://www.twilio.com/), an online telephony services gateway. Their prices are reasonable for low-volume projects and integration can be done with the following configuration:
@ -48,12 +48,12 @@ If you're managing the base domain by yourself somehow, you'll need to set up se
To make things easy for you to set up, this playbook generates and hosts 2 well-known files on the Matrix domain's server (e.g. `https://matrix.example.com/.well-known/matrix/server` and `https://matrix.example.com/.well-known/matrix/client`), even though this is the wrong place to host them.
To make things easy for you to set up, this playbook generates and hosts 2 well-known files on the Matrix domain's server (e.g. `https://matrix.example.com/.well-known/matrix/server` and `https://matrix.example.com/.well-known/matrix/client`), even though this is the wrong place to host them.
You have 2 options when it comes to installing the files on the base domain's server:
You have 3 options when it comes to installing the files on the base domain's server:
### (Option 1): **Copying the files manually** to your base domain's server
### (Option 1): **Copying the files manually** to your base domain's server
**Hint**: Option 2 (below) is generally a better way to do this. Make sure to go with that one, if possible.
**Hint**: Option 2 and 3 (below) are generally a better way to do this. Make sure to go with them, if possible.
All you need to do is:
All you need to do is:
@ -65,7 +65,16 @@ This is relatively easy to do and possibly your only choice if you can only host
It is, however, **a little fragile**, as future updates performed by this playbook may regenerate the well-known files and you may need to notice that and copy them over again.
It is, however, **a little fragile**, as future updates performed by this playbook may regenerate the well-known files and you may need to notice that and copy them over again.
### (Option 2): **Setting up reverse-proxying** of the well-known files from the base domain's server to the Matrix server
### (Option 2): **Serving the base domain** from the Matrix server via the playbook
If you don't need the base domain (e.g. `example.com`) for anything else (hosting a website, etc.), you can point it to the Matrix server's IP address and tell the playbook to configure it.
This is the easiest way to set up well-known serving -- letting the playbook handle the whole base domain for you (including SSL certificates, etc.). However, if you need to use the base domain for other things (such as hosting some website, etc.), going with Option 1 or Option 2 might be more suitable.
See [Serving the base domain](configuring-playbook-base-domain-serving.md) to learn how the playbook can help you set it up.
### (Option 3): **Setting up reverse-proxying** of the well-known files from the base domain's server to the Matrix server