Merge 255b1807a2bafff3b27f5b9651f4de29a6b2b236 into 0312ae490defae3c8561a796798453927a71f485

.github/ISSUE_TEMPLATE/feature_request.md

@@ -8,7 +8,7 @@ assignees: ''
 ---
 
 **Is your feature request related to a problem? Please describe.**
-A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+A clear and concise description of what the problem is. Ex. I'm always frustrated when […]
 
 <!--
 NOTE: When submitting feature requests, be aware that:

CHANGELOG.md

@@ -1504,7 +1504,7 @@ If you've already got both Etherpad and Dimension in use you could:
 
 - **either** keep hosting Etherpad under the Dimension domain by adding `etherpad_mode: dimension` to your `vars.yml` file. All your existing room widgets will continue working at the same URLs and no other changes will be necessary.
 
-- **or**, you could change to hosting Etherpad separately on `etherpad.example.com`. You will need to [configure a DNS record](docs/configuring-dns.md) for this new domain. You will also need to reconfigure Dimension to use the new pad URLs (`https://etherpad.example.com/...`) going forward (refer to our [configuring Etherpad documentation](docs/configuring-playbook-etherpad.md)). All your existing room widgets (which still use `https://dimension.example.com/etherpad/...`) will break as Etherpad is not hosted there anymore. You will need to re-add them or to consider not using `standalone` mode
+- **or**, you could change to hosting Etherpad separately on `etherpad.example.com`. You will need to [configure a DNS record](docs/configuring-dns.md) for this new domain. You will also need to reconfigure Dimension to use the new pad URLs (`https://etherpad.example.com/…`) going forward (refer to our [configuring Etherpad documentation](docs/configuring-playbook-etherpad.md)). All your existing room widgets (which still use `https://dimension.example.com/etherpad/…`) will break as Etherpad is not hosted there anymore. You will need to re-add them or to consider not using `standalone` mode
 
 
 # 2022-11-04
@@ -1781,7 +1781,7 @@ See our [Setting up the ntfy push notifications server](docs/configuring-playboo
 
 **TLDR**: we've made extensive **changes to metrics exposure/collection, which concern people using an external Prometheus server**. If you don't know what that is, you don't need to read below.
 
-**Why do major changes to metrics**? Because various services were exposing metrics in different, hacky, ways. Synapse was exposing metrics at `/_synapse/metrics` and `/_synapse-worker-.../metrics` on the `matrix.example.com`. The Hookshot role was **repurposing** the Granana web UI domain (`stats.example.com`) for exposing its metrics on `stats.example.com/hookshot/metrics`, while protecting these routes using Basic Authentication **normally used for Synapse** (`/_synapse/metrics`). Node-exporter and Postgres-exporter roles were advising for more `stats.example.com` usage in manual ways. Each role was doing things differently and mixing variables from other roles. Each metrics endpoint was ending up in a different place, protected by who knows what Basic Authentication credentials (if protected at all).
+**Why do major changes to metrics**? Because various services were exposing metrics in different, hacky, ways. Synapse was exposing metrics at `/_synapse/metrics` and `/_synapse-worker-…/metrics` on the `matrix.example.com`. The Hookshot role was **repurposing** the Granana web UI domain (`stats.example.com`) for exposing its metrics on `stats.example.com/hookshot/metrics`, while protecting these routes using Basic Authentication **normally used for Synapse** (`/_synapse/metrics`). Node-exporter and Postgres-exporter roles were advising for more `stats.example.com` usage in manual ways. Each role was doing things differently and mixing variables from other roles. Each metrics endpoint was ending up in a different place, protected by who knows what Basic Authentication credentials (if protected at all).
 
 **The solution**: a completely revamped way to expose metrics to an external Prometheus server. We are **introducing new `https://matrix.example.com/metrics/*` endpoints**, where various services *can* expose their metrics, for collection by external Prometheus servers. To enable the `/metrics/*` endpoints, use `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`. There's also a way to protect access using [Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication). See the `matrix-nginx-proxy` role or our [Collecting metrics to an external Prometheus server](docs/configuring-playbook-prometheus-grafana.md#collecting-metrics-to-an-external-prometheus-server) documentation for additional variables around `matrix_nginx_proxy_proxy_matrix_metrics_enabled`.
 
@@ -1800,7 +1800,7 @@ See our [Setting up the ntfy push notifications server](docs/configuring-playboo
 
 1. Exposing metrics is now done using `matrix_synapse_metrics_proxying_enabled`, not `matrix_nginx_proxy_proxy_synapse_metrics: true`. You may still need to enable metrics using `matrix_synapse_metrics_enabled: true` before exposing them.
 2. Protecting metrics endpoints using [Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) is now done in another way. See our [Collecting metrics to an external Prometheus server](docs/configuring-playbook-prometheus-grafana.md#collecting-metrics-to-an-external-prometheus-server) documentation
-3. If Synapse metrics are exposed, they will be made available at `https://matrix.example.com/metrics/synapse/main-process` or `https://matrix.example.com/metrics/synapse/worker/TYPE-ID` (when workers are enabled), not at `https://matrix.example.com/_synapse/metrics` and `https://matrix.example.com/_synapse-worker-.../metrics`
+3. If Synapse metrics are exposed, they will be made available at `https://matrix.example.com/metrics/synapse/main-process` or `https://matrix.example.com/metrics/synapse/worker/TYPE-ID` (when workers are enabled), not at `https://matrix.example.com/_synapse/metrics` and `https://matrix.example.com/_synapse-worker-…/metrics`
 4. The playbook still generates an `external_prometheus.yml.example` sample file for scraping Synapse from Prometheus as described in [Collecting Synapse worker metrics to an external Prometheus server](docs/configuring-playbook-prometheus-grafana.md#collecting-synapse-worker-metrics-to-an-external-prometheus-server), but it's now saved under `/matrix/synapse` (not `/matrix`).
 
 **If you where already using a external Prometheus server** before this change, and you gave a hashed version of the password as a variable, the playbook will now take care of hashing the password for you. Thus, you need to provide the non-hashed version now.
@@ -2779,7 +2779,7 @@ These playbook variables, with these default values, have been added:
 matrix_riot_web_default_server_name: "{{ matrix_domain }}"
 ```
 
-The login page previously said "Sign in to your Matrix account on matrix.example.org" (the homeserver's domain name). It will now say "Sign in ... on example.org" (the server name) by default, or "Sign in ... on Our Server" if you set the variable to "Our Server".
+The login page previously said "Sign in to your Matrix account on matrix.example.org" (the homeserver's domain name). It will now say "Sign in … on example.org" (the server name) by default, or "Sign in … on Our Server" if you set the variable to "Our Server".
 
 To support this, the config.json template is changed to use the configuration key `default_server_config` for setting the default HS/IS, and the new configuration key `server_name` is added in there.
 

docs/README.md

@@ -27,7 +27,7 @@ NOTE:
 
 You can check useful documentation for configuring components here: [Configuring the playbook](configuring-playbook.md)
 
-- [Administration](configuring-playbook.md#administration) -  services that help you in administrating and monitoring your Matrix installation
+- [Administration](configuring-playbook.md#administration) - services that help you in administrating and monitoring your Matrix installation
 
 - [Authentication and user-related](configuring-playbook.md#authentication-and-user-related) - extend and modify how users are authenticated on your homeserver
 

docs/ansible.md

@@ -46,7 +46,7 @@ Once you have a working Docker installation on the server, **clone the playbook*
 
 You would then need to add `ansible_connection=community.docker.nsenter` to the host line in `inventory/hosts`. This tells Ansible to connect to the "remote" machine by switching Linux namespaces with [nsenter](https://man7.org/linux/man-pages/man1/nsenter.1.html), instead of using SSH.
 
-Alternatively, you can leave your `inventory/hosts` as is and specify the connection type in **each** `ansible-playbook` call you do later, like this: `ansible-playbook --connection=community.docker.nsenter ...`
+Alternatively, you can leave your `inventory/hosts` as is and specify the connection type in **each** `ansible-playbook` call you do later, like this: `ansible-playbook --connection=community.docker.nsenter …`
 
 Run this from the playbook's directory:
 
@@ -64,7 +64,7 @@ Once you execute the above command, you'll be dropped into a `/work` directory i
 
 First, consider running `git config --global --add safe.directory /work` to [resolve directory ownership issues](#resolve-directory-ownership-issues).
 
-Finally, you can execute `ansible-playbook ...` (or `ansible-playbook --connection=community.docker.nsenter ...`) commands as per normal now.
+Finally, you can execute `ansible-playbook …` (or `ansible-playbook --connection=community.docker.nsenter …`) commands as per normal now.
 
 ### Running Ansible in a container on another computer (not the Matrix server)
 
@@ -85,13 +85,13 @@ Once you execute the above command, you'll be dropped into a `/work` directory i
 
 First, consider running `git config --global --add safe.directory /work` to [resolve directory ownership issues](#resolve-directory-ownership-issues).
 
-Finally, you execute `ansible-playbook ...` commands as per normal now.
+Finally, you execute `ansible-playbook …` commands as per normal now.
 
 #### If you don't use SSH keys for authentication
 
 If you don't use SSH keys for authentication, simply remove that whole line (`-v $HOME/.ssh/id_rsa:/root/.ssh/id_rsa:ro`).
 
-To authenticate at your server using a password, you need to add a package. So, when you are in the shell of the ansible docker container (the previously used `docker run -it ...` command), run:
+To authenticate at your server using a password, you need to add a package. So, when you are in the shell of the ansible docker container (the previously used `docker run -it …` command), run:
 
 ```sh
 apk add sshpass

docs/configuring-playbook-appservice-draupnir-for-all.md

@@ -18,7 +18,7 @@ Draupnir for all does not support external tooling like [MRU](https://mru.rory.g
 
 ## Installation
 
-### 1. Create a main management room.
+### Create a main management room.
 
 The playbook does not create a management room for your Main Draupnir. This task you have to do on your own.
 
@@ -29,11 +29,11 @@ This management room is used to control who has access to your D4A deployment. T
 As noted in the Draupnir install instructions the control room is sensitive. The following is said about the control room in the Draupnir install instructions.
 >Anyone in this room can control the bot so it is important that you only invite trusted users to this room. The room must be unencrypted since the playbook does not support installing Pantalaimon yet.
 
-### 2. Give your main management room an alias.
+### Give your main management room an alias.
 
 Give the room from step 1 an alias. This alias can be anything you want and its recommended for increased security during the setup phase of the bot that you make this alias be a random string. You can give your room a secondary human readable alias when it has been locked down after setup phase.
 
-### 3. Adjusting the playbook configuration.
+### Adjusting the playbook configuration.
 
 Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
 
@@ -45,7 +45,7 @@ matrix_appservice_draupnir_for_all_enabled: true
 matrix_appservice_draupnir_for_all_master_control_room_alias: "ALIAS_FROM_STEP_2_GOES_HERE"
 ```
 
-### 4. Installing
+### Installing
 
 After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
 
@@ -68,7 +68,7 @@ If you made it through all the steps above and your main control room was joined
 
 The installation of Draupnir for all in this playbook is very much Alpha quality. Usage-wise, Draupnir for allis almost identical to Draupnir bot mode.
 
-### 1. Granting Users the ability to use D4A
+### Granting Users the ability to use D4A
 
 Draupnir for all includes several security measures like that it only allows users that are on its allow list to ask for a bot. To add a user to this list we have 2 primary options. Using the chat to tell Draupnir to do this for us or if you want to automatically do it by sending `m.policy.rule.user` events that target the subject you want to allow provisioning for with the `org.matrix.mjolnir.allow` recomendation. Using the chat is recomended.
 
@@ -76,7 +76,7 @@ The bot requires a powerlevel of 50 in the management room to control who is all
 
 To allow users or whole homeservers you type /plain @draupnir-main:example.com allow `target` and target can be either a MXID or a wildcard like `@*:example.com` to allow all users on example.com to register. We use /plain to force the client to not attempt to mess with this command as it can break Wildcard commands especially.
 
-### 2. How to provision a D4A once you are allowed to.
+### How to provision a D4A once you are allowed to.
 
 Open a DM with @draupnir-main:example.com and if using an Element client send a message into this DM to finalise creating it. The bot will reject this invite and you will shortly get invited to the Draupnir control room for your newly provisioned Draupnir. From here its just a normal Draupnir experience.
 

docs/configuring-playbook-bot-chatgpt.md

@@ -6,7 +6,7 @@ The playbook can install and configure [matrix-chatgpt-bot](https://github.com/m
 
 Talk to [ChatGPT](https://openai.com/blog/chatgpt/) via your favourite Matrix client!
 
-## 1. Register the bot account
+## Register the bot account
 
 The playbook does not automatically create users for you. The bot requires an access token to be able to connect to your homeserver.
 
@@ -20,13 +20,13 @@ You can use the playbook to [register a new user](registering-users.md):
 ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=bot.chatgpt password=PASSWORD_FOR_THE_BOT admin=no' --tags=register-user
 ```
 
-## 2. Get an access token and create encryption keys
+## Get an access token and create encryption keys
 
 Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
 
 To make sure the bot can read encrypted messages, it will need an encryption key, just like any other new user. While obtaining the access token, follow the prompts to setup a backup key. More information can be found in the [Element documentation](https://element.io/help#encryption6).
 
-## 3. Adjusting the playbook configuration
+## Adjusting the playbook configuration
 
 Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
 
@@ -51,7 +51,7 @@ matrix_bot_chatgpt_matrix_bot_prompt_prefix: 'Instructions:\nYou are ChatGPT, a
 
 You will need to get tokens for ChatGPT.
 
-## 4. Installing
+## Installing
 
 After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
 

docs/configuring-playbook-bot-draupnir.md

@@ -8,7 +8,7 @@ This documentation page is about installing Draupnir in bot mode. As an alternat
 
 If your migrating from Mjolnir skip to step 5b.
 
-## 1. Register the bot account
+## Register the bot account
 
 The playbook does not automatically create users for you. The bot requires an access token to be able to connect to your homeserver.
 
@@ -24,11 +24,11 @@ ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=bot.draupni
 
 If you would like Draupnir to be able to deactivate users, move aliases, shutdown rooms, show abuse reports ([see below](#abuse-reports)), etc then it must be a server admin so you need to change `admin=no` to `admin=yes` in the command above.
 
-## 2. Get an access token
+## Get an access token
 
 Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
 
-## 3. Make sure the account is free from rate limiting
+## Make sure the account is free from rate limiting
 
 You will need to prevent Synapse from rate limiting the bot's account. This is not an optional step. If you do not do this step Draupnir will crash. This can be done using Synapse's [admin API](https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#override-ratelimiting-for-users). Please ask for help if you are uncomfortable with these steps or run into issues.
 
@@ -36,7 +36,7 @@ If your Synapse Admin API is exposed to the internet for some reason like runnin
 
 The following command works on semi up to date Windows 10 installs and All Windows 11 installations and other systems that ship curl. `curl --header "Authorization: Bearer <access_token>" -X POST https://matrix.example.com/_synapse/admin/v1/users/@example:example.com/override_ratelimit` Replace `@example:example.com` with the MXID of your Draupnir and example.com with your homeserver domain. You can easily obtain an access token for a homeserver admin account the same way you can obtain an access token for Draupnir itself. If you made Draupnir Admin you can just use the Draupnir token.
 
-## 4. Create a management room
+## Create a management room
 
 Using your own account, create a new invite only room that you will use to manage the bot. This is the room where you will see the status of the bot and where you will send commands to the bot, such as the command to ban a user from another room. Anyone in this room can control the bot so it is important that you only invite trusted users to this room.
 
@@ -46,11 +46,11 @@ Once you have created the room you need to copy the room ID so you can tell the
 
 Finally invite the `@bot.draupnir:example.com` account you created earlier into the room.
 
-## 5. Adjusting the playbook configuration
+## Adjusting the playbook configuration
 
 Decide whether you want Draupnir to be capable of operating in end-to-end encrypted (E2EE) rooms. This includes the management room and the moderated rooms. To support E2EE, Draupnir needs to [use Pantalaimon](configuring-playbook-pantalaimon.md).
 
-### 5a. Configuration with E2EE support
+### a. Configuration with E2EE support
 
 When using Pantalaimon, Draupnir will log in to its bot account itself through Pantalaimon, so configure its username and password.
 
@@ -85,7 +85,7 @@ matrix_bot_draupnir_homeserver_url: "{{ 'http://matrix-pantalaimon:8009' if matr
 matrix_bot_draupnir_raw_homeserver_url: "{{ matrix_addons_homeserver_client_api_url }}"
 ```
 
-### 5b. Configuration without E2EE support
+### b. Configuration without E2EE support
 
 When NOT using Pantalaimon, Draupnir does not log in by itself and you must give it an access token for its bot account.
 
@@ -101,13 +101,13 @@ matrix_bot_draupnir_access_token: "ACCESS_TOKEN_FROM_STEP_2_GOES_HERE"
 matrix_bot_draupnir_management_room: "ROOM_ID_FROM_STEP_4_GOES_HERE"
 ```
 
-### 5c. Migrating from Mjolnir (Only required if migrating.)
+### c. Migrating from Mjolnir (Only required if migrating.)
 
 Replace your `matrix_bot_mjolnir` config with `matrix_bot_draupnir` config. Also disable Mjolnir if you're doing migration.
 
 That is all you need to do due to that Draupnir can complete migration on its own.
 
-## 6. Installing
+## Installing
 
 After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
 

docs/configuring-playbook-bot-matrix-registration-bot.md

@@ -58,7 +58,7 @@ You can also refer to the upstream [Usage documentation](https://github.com/moan
 
 If you have any questions, or if you need help setting it up, read the [troublshooting guide](https://github.com/moan0s/matrix-registration-bot/blob/main/docs/troubleshooting.md) or join [#matrix-registration-bot:hyteck.de](https://matrix.to/#/#matrix-registration-bot:hyteck.de).
 
-To clean the cache (session & encryption data) after you changed the bot's username, changed the login method from access_token to password etc... you can use:
+To clean the cache (session & encryption data) after you changed the bot's username, changed the login method from access_token to password etc… you can use:
 
 ```sh
 just run-tags bot-matrix-registration-bot-clean-cache

docs/configuring-playbook-bot-mjolnir.md

@@ -4,7 +4,7 @@ The playbook can install and configure the [Mjolnir](https://github.com/matrix-o
 
 See the project's [documentation](https://github.com/matrix-org/mjolnir) to learn what it does and why it might be useful to you.
 
-## 1. Register the bot account
+## Register the bot account
 
 The playbook does not automatically create users for you. The bot requires an access token to be able to connect to your homeserver.
 
@@ -20,11 +20,11 @@ ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=bot.mjolnir
 
 If you would like Mjolnir to be able to deactivate users, move aliases, shutdown rooms, etc then it must be a server admin so you need to change `admin=no` to `admin=yes` in the command above.
 
-## 2. Get an access token
+## Get an access token
 
 Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
 
-## 3. Make sure the account is free from rate limiting
+## Make sure the account is free from rate limiting
 
 You will need to prevent Synapse from rate limiting the bot's account. This is not an optional step. If you do not do this step Mjolnir will crash. This can be done using Synapse's [admin API](https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#override-ratelimiting-for-users). Please ask for help if you are uncomfortable with these steps or run into issues.
 
@@ -32,7 +32,7 @@ If your Synapse Admin API is exposed to the internet for some reason like runnin
 
 The following command works on semi up to date Windows 10 installs and All Windows 11 installations and other systems that ship curl. `curl --header "Authorization: Bearer <access_token>" -X POST https://matrix.example.com/_synapse/admin/v1/users/@example:example.com/override_ratelimit` Replace `@example:example.com` with the MXID of your Mjolnir and example.com with your homeserver domain. You can easily obtain an access token for a homeserver admin account the same way you can obtain an access token for Mjolnir itself. If you made Mjolnir Admin you can just use the Mjolnir token.
 
-## 4. Create a management room
+## Create a management room
 
 Using your own account, create a new invite only room that you will use to manage the bot. This is the room where you will see the status of the bot and where you will send commands to the bot, such as the command to ban a user from another room. Anyone in this room can control the bot so it is important that you only invite trusted users to this room.
 
@@ -42,11 +42,11 @@ Once you have created the room you need to copy the room ID so you can tell the
 
 Finally invite the `@bot.mjolnir:example.com` account you created earlier into the room.
 
-## 5. Adjusting the playbook configuration
+## Adjusting the playbook configuration
 
 Decide whether you want Mjolnir to be capable of operating in end-to-end encrypted (E2EE) rooms. This includes the management room and the moderated rooms. To support E2EE, Mjolnir needs to [use Pantalaimon](configuring-playbook-pantalaimon.md).
 
-### 5a. Configuration with E2EE support
+### a. Configuration with E2EE support
 
 When using Pantalaimon, Mjolnir will log in to its bot account itself through Pantalaimon, so configure its username and password.
 
@@ -81,7 +81,7 @@ matrix_bot_mjolnir_homeserver_url: "{{ 'http://matrix-pantalaimon:8009' if matri
 matrix_bot_mjolnir_raw_homeserver_url: "{{ matrix_addons_homeserver_client_api_url }}"
 ```
 
-### 5b. Configuration without E2EE support
+### b. Configuration without E2EE support
 
 When NOT using Pantalaimon, Mjolnir does not log in by itself and you must give it an access token for its bot account.
 
@@ -97,7 +97,7 @@ matrix_bot_mjolnir_access_token: "ACCESS_TOKEN_FROM_STEP_2_GOES_HERE"
 matrix_bot_mjolnir_management_room: "ROOM_ID_FROM_STEP_4_GOES_HERE"
 ```
 
-## 6. Adding Mjolnir synapse antispam module (optional)
+## Adding Mjolnir synapse antispam module (optional)
 
 Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
 
@@ -109,7 +109,7 @@ matrix_synapse_ext_spam_checker_mjolnir_antispam_config_block_usernames: false
 matrix_synapse_ext_spam_checker_mjolnir_antispam_config_ban_lists: []
 ```
 
-## 7. Installing
+## Installing
 
 After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
 

docs/configuring-playbook-bridge-mautrix-discord.md

@@ -75,7 +75,7 @@ To acquire the token, open Discord in a private browser window. Then open the de
 1. Start a chat with `@discordbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
 2. If you would like to login to Discord using a token, send `login-token` command, otherwise, send `login-qr` command.
 3. You'll see a QR code which you need to scan with the Discord app on your phone. You can scan it with the camera app too, which will open Discord, which will then instruct you to scan it a 2nd time in the Discord app.
-4. After confirming (in the Discord app) that you'd like to allow this login, the bot should respond with "Succcessfully authenticated as ..."
+4. After confirming (in the Discord app) that you'd like to allow this login, the bot should respond with "Succcessfully authenticated as …"
 5. Now that you're logged in, you can send a `help` command to the bot again, to see additional commands you have access to
 6. Some Direct Messages from Discord should start syncing automatically
 7. If you'd like to bridge guilds:

docs/configuring-playbook-pantalaimon.md

@@ -6,7 +6,7 @@ See the project's [documentation](https://github.com/matrix-org/pantalaimon) to
 
 This role exposes Pantalaimon's API only within the container network, so bots and clients installed on the same machine can use it. In particular the [Draupnir](configuring-playbook-bot-draupnir.md) and [Mjolnir](configuring-playbook-bot-mjolnir.md) roles (and possibly others) can use it.
 
-## 1. Adjusting the playbook configuration
+## Adjusting the playbook configuration
 
 Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
 
@@ -16,7 +16,7 @@ matrix_pantalaimon_enabled: true
 
 The default configuration should suffice. For advanced configuration, you can override the variables documented in the role's [defaults](../roles/custom/matrix-pantalaimon/defaults/main.yml).
 
-## 2. Installing
+## Installing
 
 After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
 

docs/configuring-playbook-user-verification-service.md

@@ -59,7 +59,7 @@ It is possible to set an API Auth Token to restrict access to the UVS. If this i
 
 By default, the token will be derived from `matrix_homeserver_generic_secret_key` in `group_vars/matrix_servers`.
 
-To set your own Token, simply put the following in your host_vars.
+To set your own Token, add the following configuration to your `vars.yml` file:
 
 ```yaml
 matrix_user_verification_service_uvs_auth_token: "TOKEN"
@@ -67,26 +67,22 @@ matrix_user_verification_service_uvs_auth_token: "TOKEN"
 
 In case Jitsi is also managed by this playbook and 'matrix' authentication in Jitsi is enabled, this collection will automatically configure Jitsi to use the configured auth token.
 
-###  (Optional) Disable Auth
+### (Optional) Disable Auth
 
-Authorization is enabled by default. To disable set
+Authorization is enabled by default. To disable it, add the following configuration to your `vars.yml` file:
 
 ```yaml
 matrix_user_verification_service_uvs_require_auth: false
 ```
 
-in your host_vars.
-
 ### (Optional) Federation
 
-In theory (however currently untested), UVS can handle federation. Simply set:
+In theory (however currently untested), UVS can handle federation. To enable it, add the following configuration to your `vars.yml` file:
 
 ```yaml
 matrix_user_verification_service_uvs_pin_openid_verify_server_name: false
 ```
 
-in your host_vars.
-
 This will instruct UVS to verify the OpenID token against any domain given in a request. Homeserver discovery is done via '.well-known/matrix/server' of the given domain.
 
 ## Installing

docs/faq.md

@@ -393,7 +393,7 @@ You generally need to do a playbook installation. It's recommended to follow the
 
 This Ansible playbook guides you into installing a server for `example.com` (user identifiers are like this: `@user:example.com`), while the server is at `matrix.example.com`. If your existing setup has a server name (`server_name` configuration setting in Synapse's `homeserver.yaml` file) other than the base `example.com`, you may need to tweak some additional variables. This FAQ entry may be of use if you're dealing with a more complicated setup - [How do I install on matrix.example.com without involving the base domain?](#how-do-i-install-on-matrixexamplecom-without-involving-the-base-domain)
 
-After configuring the playbook and installing and **before starting** services (done with `ansible-playbook ... --tags=start`) you'd import [your SQLite](importing-synapse-sqlite.md) (or [Postgres](importing-postgres.md)) database and also [import your media store](importing-synapse-media-store.md).
+After configuring the playbook and installing and **before starting** services (done with `ansible-playbook … --tags=start`) you'd import [your SQLite](importing-synapse-sqlite.md) (or [Postgres](importing-postgres.md)) database and also [import your media store](importing-synapse-media-store.md).
 
 ### I've downloaded Ansible and the playbook on the server. It can't connect using SSH.
 

docs/importing-postgres.md

@@ -9,7 +9,7 @@ For this to work, **the database name in Postgres must match** what this playboo
 
 The playbook supports importing Postgres dump files in **text** (e.g. `pg_dump > dump.sql`) or **gzipped** formats (e.g. `pg_dump | gzip -c > dump.sql.gz`). Importing multiple databases (as dumped by `pg_dumpall`) is also supported.
 
-The migration might be a good moment, to "reset" a not properly working bridge. Be aware, that it might affect all users (new link to bridge, new rooms, ...)
+The migration might be a good moment, to "reset" a not properly working bridge. Be aware, that it might affect all users (new link to bridge, new rooms, …)
 
 Before doing the actual import, **you need to upload your Postgres dump file to the server** (any path is okay).
 
@@ -55,7 +55,7 @@ ALTER TABLE public.account_data OWNER TO synapse_user;
 ALTER TABLE public.account_data_max_stream_id OWNER TO synapse_user;
 ALTER TABLE public.account_validity OWNER TO synapse_user;
 ALTER TABLE public.application_services_state OWNER TO synapse_user;
-...
+…
 ```
 
 It can be worked around by changing the username to `synapse`, for example by using `sed`:
@@ -64,7 +64,7 @@ It can be worked around by changing the username to `synapse`, for example by us
 $ sed -i "s/OWNER TO synapse_user;/OWNER TO synapse;/g" homeserver.sql
 ```
 
-This uses sed to perform an 'in-place' (`-i`) replacement globally (`/g`), searching for `synapse_user` and replacing with `synapse` (`s/synapse_user/synapse`). If your database username was different, change `synapse_user` to that username instead. Expand search/replace statement as shown in example above, in case of old user name like `matrix` - replacing `matrix` only would... well - you can imagine.
+This uses sed to perform an 'in-place' (`-i`) replacement globally (`/g`), searching for `synapse_user` and replacing with `synapse` (`s/synapse_user/synapse`). If your database username was different, change `synapse_user` to that username instead. Expand search/replace statement as shown in example above, in case of old user name like `matrix` - replacing `matrix` only would… well - you can imagine.
 
 Note that if the previous import failed with an error it may have made changes which are incompatible with re-running the import task right away; if you do so it may fail with an error such as:
 

examples/reverse-proxies/caddy2-in-container/docker-compose.yaml

@@ -14,7 +14,7 @@ services:
     volumes:
       - ./Caddyfile:/etc/caddy/Caddyfile
       # - ./site:/var/www
-    #  Other configurations ...
+    #  Other configurations …
 
 networks:
   # add this as well

justfile

@@ -17,18 +17,18 @@ roles:
 update *flags: update-playbook-only
     #!/usr/bin/env sh
     if [ -x "$(command -v agru)" ]; then
-        echo {{ if flags == "" { "Installing roles pinned in requirements.yml..." } else if flags == "-u" { "Updating roles and pinning new versions in requirements.yml..." } else { "Unknown flags passed" } }}
+        echo {{ if flags == "" { "Installing roles pinned in requirements.yml…" } else if flags == "-u" { "Updating roles and pinning new versions in requirements.yml…" } else { "Unknown flags passed" } }}
         agru {{ flags }}
     else
         echo "[NOTE] You are using the standard ansible-galaxy tool to install roles, which is slow and lacks other features. We recommend installing the 'agru' tool to speed up the process: https://github.com/etkecc/agru#where-to-get"
-        echo "Installing roles..."
+        echo "Installing roles…"
         rm -rf roles/galaxy
         ansible-galaxy install -r requirements.yml -p roles/galaxy/ --force
     fi
 
 # Updates the playbook without installing/updating Ansible roles
 update-playbook-only:
-    @echo "Updating playbook..."
+    @echo "Updating playbook…"
     @git stash -q
     @git pull -q
     @-git stash pop -q

roles/custom/matrix-base/templates/bin/remove-all.j2

@@ -6,7 +6,7 @@ if [ "$(id -u)" != "0" ]; then
 	exit 1
 fi
 
-echo "WARNING! You are about to remove everything the playbook installs for {{ matrix_server_fqn_matrix }}: matrix, docker images,..."
+echo "WARNING! You are about to remove everything the playbook installs for {{ matrix_server_fqn_matrix }}: matrix, docker images, …"
 echo -n "If you're sure you want to do this, type: 'Yes, I really want to remove everything!'"
 read sure
 

roles/custom/matrix-bridge-appservice-irc/defaults/main.yml

@@ -95,7 +95,7 @@ matrix_appservice_irc_ircService_servers: []  # noqa var-naming
 #     # A specific CA to trust instead of the default CAs. Optional.
 #     #ca: |
 #     #  -----BEGIN CERTIFICATE-----
-#     #  ...
+#     #  …
 #     #  -----END CERTIFICATE-----
 
 #     #

roles/custom/matrix-bridge-hookshot/defaults/main.yml

@@ -90,7 +90,7 @@ matrix_hookshot_github_auth_id: ''
 # Set this variable to the contents of the generated and downloaded GitHub private key:
 # matrix_hookshot_github_private_key: |
 #   -----BEGIN RSA PRIVATE KEY-----
-#   0123456789ABCDEF...
+#   0123456789ABCDEF…
 #   -----END RSA PRIVATE KEY-----
 # Alternatively, leave it empty and do it manually or use matrix-aux instead, see docs/matrix-bridge-hookshot.md for info.
 matrix_hookshot_github_private_key: ''

roles/custom/matrix-dendrite/templates/dendrite.yaml.j2

@@ -12,7 +12,7 @@
 # for "connection_string":
 #   SQLite:     file:filename.db
 #               file:///path/to/filename.db
-#   PostgreSQL: postgresql://user:pass@hostname/database?params=...
+#   PostgreSQL: postgresql://user:pass@hostname/database?params=…
 #
 # SQLite is embedded into Dendrite and therefore no further prerequisites are
 # needed for the database when using SQLite mode. However, performance with

roles/custom/matrix-synapse-reverse-proxy-companion/defaults/main.yml

@@ -190,7 +190,7 @@ matrix_synapse_reverse_proxy_companion_send_timeout: 60
 # For OCSP purposes, we need to define a resolver at the `server{}` level or `http{}` level (we do the latter).
 #
 # Otherwise, we get warnings like this:
-# > [warn] 22#22: no resolver defined to resolve r3.o.lencr.org while requesting certificate status, responder: r3.o.lencr.org, certificate: "/matrix/ssl/config/live/.../fullchain.pem"
+# > [warn] 22#22: no resolver defined to resolve r3.o.lencr.org while requesting certificate status, responder: r3.o.lencr.org, certificate: "/matrix/ssl/config/live/…/fullchain.pem"
 #
 # We point it to the internal Docker resolver, which likely delegates to nameservers defined in `/etc/resolv.conf`.
 matrix_synapse_reverse_proxy_companion_http_level_resolver: 127.0.0.11

roles/custom/matrix-synapse/defaults/main.yml

@@ -78,7 +78,7 @@ matrix_synapse_container_image_customizations_templates_git_repository_keyscan_h
 
 # matrix_synapse_container_image_customizations_dockerfile_body contains your custom Dockerfile steps
 # for building your customized Synapse image based on the original (upstream) image (`matrix_synapse_docker_image`).
-# A `FROM ...` clause is included automatically so you don't have to.
+# A `FROM …` clause is included automatically so you don't have to.
 #
 # Example:
 # matrix_synapse_container_image_customizations_dockerfile_body_custom: |
@@ -1439,7 +1439,7 @@ matrix_synapse_media_storage_providers_auto: |
 # matrix_synapse_media_storage_providers_custom:
 # - module: module.SomeModule
 #   store_local: True
-#   # ...
+#   # …
 matrix_synapse_media_storage_providers_custom: []
 
 matrix_synapse_encryption_enabled_by_default_for_room_type: "off"

roles/custom/matrix-synapse/templates/synapse/homeserver.yaml.j2

@@ -55,7 +55,7 @@ pid_file: /homeserver.pid
 #web_client_location: https://riot.example.com/
 
 # The public-facing base URL that clients use to access this Homeserver (not
-# including _matrix/...). This is the same URL a user might enter into the
+# including _matrix/…). This is the same URL a user might enter into the
 # 'Custom Homeserver URL' field on their client. If you use Synapse with a
 # reverse proxy, this should be the URL to reach Synapse via the proxy.
 # Otherwise, it should be the URL to reach Synapse's client HTTP listener (see
@@ -2462,34 +2462,34 @@ email:
     #
     # Subject to use to notify about one message from one or more user(s) in a
     # room which has a name.
-    #message_from_person_in_room: "[%(app)s] You have a message on %(app)s from %(person)s in the %(room)s room..."
+    #message_from_person_in_room: "[%(app)s] You have a message on %(app)s from %(person)s in the %(room)s room…"
     #
     # Subject to use to notify about one message from one or more user(s) in a
     # room which doesn't have a name.
-    #message_from_person: "[%(app)s] You have a message on %(app)s from %(person)s..."
+    #message_from_person: "[%(app)s] You have a message on %(app)s from %(person)s…"
     #
     # Subject to use to notify about multiple messages from one or more users in
     # a room which doesn't have a name.
-    #messages_from_person: "[%(app)s] You have messages on %(app)s from %(person)s..."
+    #messages_from_person: "[%(app)s] You have messages on %(app)s from %(person)s…"
     #
     # Subject to use to notify about multiple messages in a room which has a
     # name.
-    #messages_in_room: "[%(app)s] You have messages on %(app)s in the %(room)s room..."
+    #messages_in_room: "[%(app)s] You have messages on %(app)s in the %(room)s room…"
     #
     # Subject to use to notify about multiple messages in multiple rooms.
-    #messages_in_room_and_others: "[%(app)s] You have messages on %(app)s in the %(room)s room and others..."
+    #messages_in_room_and_others: "[%(app)s] You have messages on %(app)s in the %(room)s room and others…"
     #
     # Subject to use to notify about multiple messages from multiple persons in
     # multiple rooms. This is similar to the setting above except it's used when
     # the room in which the notification was triggered has no name.
-    #messages_from_person_and_others: "[%(app)s] You have messages on %(app)s from %(person)s and others..."
+    #messages_from_person_and_others: "[%(app)s] You have messages on %(app)s from %(person)s and others…"
     #
     # Subject to use to notify about an invite to a room which has a name.
-    #invite_from_person_to_room: "[%(app)s] %(person)s has invited you to join the %(room)s room on %(app)s..."
+    #invite_from_person_to_room: "[%(app)s] %(person)s has invited you to join the %(room)s room on %(app)s…"
     #
     # Subject to use to notify about an invite to a room which doesn't have a
     # name.
-    #invite_from_person: "[%(app)s] %(person)s has invited you to chat on %(app)s..."
+    #invite_from_person: "[%(app)s] %(person)s has invited you to chat on %(app)s…"
 
     # Subject for emails related to account administration.
     #

roles/custom/matrix-synapse/vars/main.yml

@@ -246,7 +246,7 @@ matrix_synapse_workers_media_repository_endpoints:
   - ^/_matrix/client/v1/media/
   - ^/_matrix/federation/v1/media/
 
-  # ... and the following regular expressions matching media-specific administration APIs:
+  # … and the following regular expressions matching media-specific administration APIs:
 
   - ^/_synapse/admin/v1/purge_media_cache$
   - ^/_synapse/admin/v1/room/.*/media.*$