Fix syntax in matrix-bridge-hookshot/tasks/reset_encryption.yml

Also, this task always does work and side-effects, so it should always report changes
(`changed_when: true`).

.github/renovate.json

@@ -15,6 +15,7 @@
 		{
 			"matchSourceUrlPrefixes": [
 				"https://github.com/devture/com.devture.ansible.role",
+				"https://gitlab.com/etke.cc/roles",
 				"https://github.com/mother-of-all-self-hosting"
 			],
 			"ignoreUnstable": false

.github/workflows/matrix.yml

@@ -13,7 +13,7 @@ jobs:
       - name: Check out
         uses: actions/checkout@v4
       - name: Run yamllint
-        uses: frenck/action-yamllint@v1.5.0
+        uses: frenck/action-yamllint@v1.4.2
   ansible-lint:
     name: ansible-lint
     runs-on: ubuntu-latest

.gitignore

@@ -1,9 +1,12 @@
-/inventory
+/inventory/*
+!/inventory/.gitkeep
+!/inventory/host_vars/.gitkeep
+!/inventory/scripts
 /roles/**/files/scratchpad
 .DS_Store
 .python-version
 .idea/
-.direnv/
+flake.lock
 
 # ignore roles pulled by ansible-galaxy
 /roles/galaxy/*

CHANGELOG.md

@@ -1,690 +1,3 @@
-# 2024-09-27
-
-## (BC Break) Postgres & Traefik roles have been relocated and variable names need adjustments
-
-Various roles have been relocated from the [devture](https://github.com/devture) organization to the [mother-of-all-self-hosting](https://github.com/mother-of-all-self-hosting) organization.
-
-Along with the relocation, the `devture_` prefix was dropped from their variable names, so you need to adjust your `vars.yml` configuration.
-
-You need to do the following replacements:
-
-- `devture_postgres_` -> `postgres_`
-- `devture_traefik_` -> `traefik_`
-
-As always, the playbook would let you know about this and point out any variables you may have missed.
-
-
-# 2024-09-12
-
-## Support for baibot
-
-The playbook now supports installing [baibot](./docs/configuring-playbook-bot-baibot.md) (pronounced bye-bot) - a [Matrix](https://matrix.org/) bot developed by [etke.cc](https://etke.cc/) that exposes the power of [AI](https://en.wikipedia.org/wiki/Artificial_intelligence) / [Large Language Models](https://en.wikipedia.org/wiki/Large_language_model) to you. 🤖
-
-It supports [OpenAI](https://openai.com/)'s [ChatGPT](https://openai.com/blog/chatgpt/) models, as well as many other [☁️ providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md).
-
-It's designed as a more private and [✨ featureful](https://github.com/etkecc/baibot/?tab=readme-ov-file#-features) alternative to the now-unmaintained [matrix-chatgpt-bot](./docs/configuring-playbook-bot-chatgpt.md).
-
-To get started, see the [Setting up baibot](./docs/configuring-playbook-bot-baibot.md) documentation page.
-
-
-## Switching synapse-admin to etke.cc's fork
-
-The playbook now installs [etke.cc](https://etke.cc/)'s [fork](https://github.com/etkecc/synapse-admin) of [synapse-admin](https://github.com/Awesome-Technologies/synapse-admin) (originally developed by [Awesome-Technologies](https://github.com/Awesome-Technologies)). This fork is a drop-in replacement for the original software.
-
-The creation of the fork has been provoked by users frequently encountering issues with the original synapse-admin software, such as unintentionally deleting their one-and-only admin user account (fixed [here](https://github.com/etkecc/synapse-admin/pull/1) and also contributed upstream [here](https://github.com/Awesome-Technologies/synapse-admin/pull/608) - to no avail for now). Since its inception, [a bunch of other quality-of-life improvements](https://github.com/etkecc/synapse-admin?tab=readme-ov-file#changes) have been made to the fork.
-
-If upstream synapse-admin picks up the pace and improves, the etke.cc fork may disappear and the playbook may switch to the original software again. Until that time comes, we believe that etke.cc's fork is the better software to use right now.
-
-If you'd like to switch back to the original synapse-admin software, you can do so by adding the following configuration to your `vars.yml` file:
-
-```yml
-matrix_synapse_admin_docker_image: "{{ matrix_synapse_admin_docker_image_name_prefix }}awesometechnologies/synapse-admin:{{ matrix_synapse_admin_version }}"
-matrix_synapse_admin_docker_image_name_prefix: "{{ 'localhost/' if matrix_synapse_admin_container_image_self_build else matrix_container_global_registry_prefix }}"
-
-matrix_synapse_admin_version: 0.10.3
-
-# If you need self-building (if running on arm32), uncomment this.
-# matrix_synapse_admin_container_image_self_build_repo: "https://github.com/Awesome-Technologies/synapse-admin.git"
-```
-
-
-# 2024-08-17
-
-## New appservice-double-puppet service for better double-puppeting
-
-Mautrix bridges are undergoing large changes as announced in the [August 2024 releases & progress](https://mau.fi/blog/2024-08-mautrix-release/) blog post.
-
-The playbook has already upgraded to the rewritten mautrix-slack ([v0.1.0](https://github.com/mautrix/slack/releases/tag/v0.1.0)) and mautrix-signal ([v0.7.0](https://github.com/mautrix/signal/releases/tag/v0.7.0)) bridges.
-
-The newly rewritten bridges do not support double-puppeting via [Shared Secret Auth](./docs/configuring-playbook-shared-secret-auth.md) anymore, which has prompted us to switch to the new & better [appservice method](https://docs.mau.fi/bridges/general/double-puppeting.html#appservice-method-new) for double-puppeting. The playbook automates this double-puppeting setup for you if you enable the new [Appservice Double Puppet](./docs/configuring-playbook-appservice-double-puppet.md) service.
-
-All non-deprecated mautrix bridges in the playbook have been reworked to support double-puppeting via an Appservice. Most bridges still support double-puppeting via [Shared Secret Auth](./docs/configuring-playbook-shared-secret-auth.md), so the playbook supports it too. If only Shared Secret Auth is enabled, double-puppeting will be configured using that method (for the bridges that support it). That said, **Shared Secret Auth double-puppeting is being phased out and we recommend replacing it with the new Appservice method**.
-
-We recommend **enabling double-puppeting via the new Appservice method** by adding the following configuration to your `vars.yml` file:
-
-```yml
-matrix_appservice_double_puppet_enabled: true
-```
-
-You can still **keep** [Shared Secret Auth](./docs/configuring-playbook-shared-secret-auth.md) enabled. Non-mautrix bridges and other services (e.g. [matrix-corporal](./docs/configuring-playbook-matrix-corporal.md)) may still require it.
-
-When both double-puppeting methods are enabled, the playbook will automatically choose the new and better Appservice method for bridges that support it.
-
-
-# 2024-08-15
-
-## matrix-media-repo now configured for Authenticated Media
-
-Thanks to [Michael Hollister](https://github.com/Michael-Hollister) from [FUTO](https://www.futo.org/), our matrix-media-repo implementation now automatically [sets up signing keys](https://docs.t2bot.io/matrix-media-repo/v1.3.5/installation/signing-key/) for Authenticated Media (as per [MSC3916](https://github.com/matrix-org/matrix-spec-proposals/pull/3916)).
-
-If you had never heard of Authenticated Media before, the [Sunsetting unauthenticated media](https://matrix.org/blog/2024/06/26/sunsetting-unauthenticated-media/) article on [matrix.org](https://matrix.org/) is a good introduction.
-
-This feature is enabled for matrix-media-repo installations by default and will append an additional (matrix-media-repo-generated signing key) to your homeserver's (Synapse or Dendrite) signing key. See the [Signing keys](./docs/configuring-playbook-matrix-media-repo.md#signing-keys) and [Key backup and revoking](./docs/configuring-playbook-matrix-media-repo.md#key-backup-and-revoking) sections of the matrix-media-repo documentation for more details.
-
-If you'd like to avoid this new feature, you can disable it by setting `matrix_media_repo_generate_signing_key: false` in your `vars.yml` configuration file.
-
-
-# 2024-08-08
-
-## (Backward Compatibility Break) matrix-corporal has been upgraded to v3
-
-The playbook now installs [matrix-corporal](https://github.com/devture/matrix-corporal) v3.0.0, which brings support for **power-level management** (thanks to [this PR](https://github.com/devture/matrix-corporal/pull/32)).
-
-This upgrade necessitates configuration policy changes as described in [matrix-corporal's changelog entry](https://github.com/devture/matrix-corporal/blob/5287cb81c82cd3b951c2a099b4697c3e0b384559/CHANGELOG.md#version-300-2024-08-08).
-
-If you'd like to remain on the old (v2) version of matrix-corporal, you can do so by adding the following configuration to your `vars.yml` file:
-
-```yml
-matrix_corporal_version: 2.8.0
-```
-
-# 2024-07-25
-
-## synapse-usage-exporter support
-
-Thanks to [Michael Hollister](https://github.com/Michael-Hollister) from [FUTO](https://www.futo.org/), the creators of the [Circles app](https://circu.li/), the playbook can now set up [synapse-usage-exporter](https://github.com/loelkes/synapse-usage-exporter) - a small [Flask](https://flask.palletsprojects.com)-based webservice which can capture usage statistics from Synapse (via HTTP `PUT`) and then make them available for Prometheus to scrape.
-
-To learn more see our [Enabling synapse-usage-exporter for Synapse usage statistics](docs/configuring-playbook-synapse-usage-exporter.md) documentation page.
-
-
-# 2024-07-06
-
-## matrix-alertmanager-receiver support
-
-For those wishing to more easily integrate [Prometheus](https://prometheus.io/)' alerting service ([Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/)) with Matrix, the playbook can now set up [matrix-alertmanager-receiver](https://github.com/metio/matrix-alertmanager-receiver).
-
-See [Setting up Prometheus Alertmanager integration via matrix-alertmanager-receiver](./docs/configuring-playbook-alertmanager-receiver.md) for more details.
-
-
-## Traefik v3 and HTTP/3 are here now
-
-**TLDR**: Traefik was migrated from v2 to v3. Minor changes were done to the playbook. Mostly everything else worked out of the box. Most people will not have to do any tweaks to their configuration. In addition, [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3) support is now auto-enabled for the `web-secure` (port 443) and `matrix-federation` (port `8448`) entrypoints. If you have a firewall in front of your server and you wish to benefit from `HTTP3`, you will need to open the `443` and `8448` UDP ports in it.
-
-### Traefik v3
-
-The reverse-proxy that the playbook uses by default (Traefik) has recently been upgraded to v3 (see [this blog post](https://traefik.io/blog/announcing-traefik-proxy-v3-rc/) to learn about its new features). Version 3 includes some small breaking configuration changes requiring a [migration](https://doc.traefik.io/traefik/migration/v2-to-v3/).
-
-We have **updated the playbook to Traefik v3** (make sure to run `just roles` / `make roles` to get it).
-
-There were **only minor playbook changes required** to adapt to Traefik v3, and only to the Ansible role for [matrix-media-repo](./docs/configuring-playbook-matrix-media-repo.md) where we changed a few [`PathPrefix` instances to `PathRegexp`](https://doc.traefik.io/traefik/routing/routers/#path-pathprefix-and-pathregexp), because these instances were using a regular expression instead of a fixed path. For fixed-path values, `PathPrefix` is still the preferred matcher function to use.
-
-**Most people using the playbook should not have to do any changes**.
-
-If you're using the playbook's Traefik instance to reverse-proxy to some other services of your own (not managed by the playbook), you may wish to review their Traefik labels and make sure they're in line with the [Traefik v2 to v3 migration guide](https://doc.traefik.io/traefik/migration/v2-to-v3/).
-
-If you've tweaked any of this playbook's `_path_prefix` variables and made them use a regular expression, you will now need to make additional adjustments. The playbook makes extensive use of `PathPrefix()` matchers in Traefik rules and `PathPrefix` does not support regular expressions anymore. To work around it, you may now need to override a whole `_traefik_rule` variable and switch it from [`PathPrefix` to `PathRegexp`](https://doc.traefik.io/traefik/routing/routers/#path-pathprefix-and-pathregexp).
-
-If you're not using [matrix-media-repo](./docs/configuring-playbook-matrix-media-repo.md) (the only role we had to tweak to adapt it to Traefik v3), you **may potentially downgrade to Traefik v2** (if necessary) by adding `traefik_verison: v2.11.4` to your configuration. People using `matrix-media-repo` cannot downgrade this way, because `matrix-media-repo` has been adjusted to use `PathRegexp` - a [routing matcher](https://doc.traefik.io/traefik/v2.11/routing/routers/#rule) that Traefik v2 does not understand.
-
-
-### HTTP/3 is enabled by default
-
-In Traefik v3, [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3) support is no longer considered experimental now.
-Due to this, **the playbook auto-enables HTTP3** for the `web-secure` (port 443) and `matrix-federation` (port `8448`) entrypoints.
-
-HTTP3 uses the UDP protocol and **the playbook (together with Docker) will make sure that the appropriate ports** (`443` over UDP & `8448` over UDP) **are exposed and whitelisted in your server's firewall**. However, **if you have another firewall in front of your server** (as is the case for many cloud providers), **you will need to manually open these UDP ports**.
-
-If you do not open the UDP ports correctly or there is some other issue, clients (browsers, mostly) will fall-back to [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2) or even [HTTP/1.1](https://en.wikipedia.org/wiki/HTTP).
-
-Still, if HTTP/3 cannot function correctly in your setup, it's best to disable advertising support for it (and misleading clients into trying to use HTTP/3).
-
-To **disable HTTP/3**, you can use the following configuration:
-
-```yml
-traefik_config_entrypoint_web_secure_http3_enabled: false
-
-# Disabling HTTP/3 for the web-secure entrypoint (above),
-# automatically disables it for the Matrix Federation entrypoint as well,
-# so you do not necessarily need the configuration line below.
-#
-# Feel free to only keep it around if you're keeping HTTP/3 enabled for web-secure (by removing the line above),
-# and would only like to disable HTTP/3 for the Matrix Federation entrypoint.
-matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_http3_enabled: false
-```
-
-If you are using [your own webserver](./docs/configuring-playbook-own-webserver.md) (in front of Traefik), port binding on UDP port `8448` by default due to HTTP/3 is either unnecessary or [may get in the way](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3402). If it does, you can disable it:
-
-```yml
-# Disable HTTP/3 for the federation entrypoint.
-# If you'd like HTTP/3, consider configuring it for your other reverse-proxy.
-#
-# Disabling this also sets `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port_udp` to an empty value.
-# If you'd like to keep HTTP/3 enabled here (for whatever reason), you may wish to explicitly
-# set `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port_udp` to something like '127.0.0.1:8449'.
-matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_http3_enabled: false
-```
-
-
-# 2024-07-01
-
-## synapse-admin is now restricted to your homeserver's URL by default
-
-A new feature introduced in synapse-admin [v0.10.0](https://github.com/Awesome-Technologies/synapse-admin/releases/tag/0.10.0) (released and supported by the playbook since a a few months ago) provides the ability to [restrict its usage to a specific homeserver](https://github.com/Awesome-Technologies/synapse-admin/blob/e21e44362c879ac41f47c580b04210842b6ff3d7/README.md#restricting-available-homeserver) (or multiple homeservers).
-
-The playbook has just started making use of this feature. **From now on, your synapse-admin instance will be restricted to the homeserver you're managing via the playbook**. When configured like this, the *Homeserver URL* field in synapse-admin's web UI changes from a text field to a dropdown having a single value (the URL of your homeserver). This makes usage simpler for most people, as they won't need to manually enter a *Homeserver URL* anymore.
-
-If you'd like **to go back to the old unrestricted behavior**, use the following configuration:
-
-```yml
-# Use this configuration to allow synapse-admin to manage any homeserver instance.
-matrix_synapse_admin_config_restrictBaseUrl: []
-```
-
-
-# 2024-06-25
-
-## The URL-prefix for Hookshot generic webhooks has changed
-
-Until now, generic Hookshot webhook URLs looked like this: `https://matrix.DOMAIN/hookshot/webhooks/:hookId`.
-
-The `/hookshot/webhooks` common prefix gets stripped by Traefik automatically, so Hookshot only sees the part that comes after (`/:hookId`).
-
-[A few years ago](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1681), Hookshot started to prefer to handle webhooks at a `/webhook/:hookId` path (instead of directly at `/:hookId`).
-
-To avoid future problems, we've [reconfigured](https://github.com/spantaleev/matrix-docker-ansible-deploy/commit/4704a60718946fd469aeee7fc3ae8127c633bb6b) our Hookshot configuration to use webhook URLs that include `/webhook` in the URL suffix (e.g. `/hookshot/webhooks/webhook/:hookId`, instead of `/hookshot/webhooks/:hookId`). This means that when we strip the common prefi (`/hookshot/webhooks`), we'll end up sending `/webhook/:hookId` to Hookshot, just like recommended.
-
-When generating new webhooks, you should start seeing the new URLs being used.
-
-**For now**, **both** old URLs (`/hookshot/webhooks/:hookId`) and new URLs (`/hookshot/webhooks/webhook/:hookId`) **continue to work***, so your webhooks will not break just yet.
-
-However, **we recommend that you update all your old webhook URLs** (configured in other systems) to include the new `/webhook` path component, so that future Hookshot changes (whenever they come) will not break your webhooks. You don't need to do anything on the Hookshot side - you merely need to reconfigure the remote systems that use your webhook URLs.
-
-
-
-# 2024-06-22
-
-## The maubot user is now managed by the playbook
-
-To make things easier and to be consistent with other roles, the [maubot](./docs/configuring-playbook-bot-maubot.md) user (`bot.maubot` by default) is [now](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3376) automatically created be the playbook.
-
-If you have an existing maubot installation, you will need to specify `matrix_bot_maubot_initial_password` in your `vars.yml` file to make the playbook not complain about it being undefined.
-Since the bot is already registered in your installation, there's nothing for the playbook to do anyway. In case you don't remember the password you've registered your maubot user account with, you can specify any value for this variable.
-
-If you've registered another username for the bot (other than the recommended default of `bot.maubot`), consider adjusting the `matrix_bot_maubot_login` variable (e.g. `matrix_bot_maubot_login: my.maubot.username`).
-
-
-# 2024-06-03
-
-## WeChat bridging support
-
-Thanks to [Tobias Diez](https://github.com/tobiasdiez)'s [efforts](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3241), the playbook now supports bridging to [WeChat](https://www.wechat.com/) via the [matrix-wechat](https://github.com/duo/matrix-wechat) bridge.
-
-See our [Setting up WeChat bridging](docs/configuring-playbook-bridge-wechat.md) documentation page for getting started.
-
-
-# 2024-03-26
-
-## (Backward Compatibility Break) The playbook now defaults to KeyDB, instead of Redis
-
-**TLDR**: if the playbook used installed Redis as a dependency for you before, it will now replace it with [KeyDB](https://docs.keydb.dev/) (a drop-in alternative) due to [Redis having changed its license](https://redis.com/blog/redis-adopts-dual-source-available-licensing/).
-
-Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook now uses [KeyDB](https://docs.keydb.dev/) (a drop-in alternative for Redis), instead of [Redis](https://redis.io/).
-
-The playbook used to install Redis (and now installs KeyDB in its place) if services have a need for it ([enabling worker support for Synapse](docs/configuring-playbook-synapse.md#load-balancing-with-workers), [enabling Hookshot encryption](docs/configuring-playbook-bridge-hookshot.md#end-to-bridge-encryption), etc.) or if you explicitly enabled the service (`redis_enabled: true` or `keydb_enabled: true`).
-
-This change is provoked by the fact that [Redis is now "source available"](https://redis.com/blog/redis-adopts-dual-source-available-licensing/). According to the Limitations of [the new license](https://redis.com/legal/rsalv2-agreement/) (as best as we understand them, given that we're not lawyers), using Redis in the playbook (even in a commercial FOSS service like [etke.cc](https://etke.cc/)) does not violate the new Redis license. That said, we'd rather neither risk it, nor endorse shady licenses and products that pretend to be free-software. Another high-quality alternative to Redis seems to be [Dragonfly](https://www.dragonflydb.io/), but the [Dragonfly license](https://github.com/dragonflydb/dragonfly?tab=License-1-ov-file#readme) is no better than Redis's.
-
-Next time your run the playbook (via the `setup-all` tag), **Redis will be automatically uninstalled and replaced with KeyDB**. Some Synapse downtime may occur while the switch happens.
-
-Users on `arm32` should be aware that there's **neither a prebuilt `arm32` container image for KeyDB**, nor the KeyDB role supports self-building yet. Users on this architecture likely don't run Synapse with workers, etc., so they're likely in no need of KeyDB (or Redis). If Redis is necessary in an `arm32` deployment, disabling KeyDB and making the playbook fall back to Redis is possible (see below).
-
-**The playbook still supports Redis** and you can keep using Redis (for now) if you'd like, by adding this additional configuration to your `vars.yml` file:
-
-```yml
-# Explicitly disable KeyDB, which will auto-enable Redis
-# if the playbook requires it as a dependency for its operation.
-keydb_enabled: false
-```
-
-
-
-# 2024-03-24
-
-## Initial work on IPv6 support
-
-Thanks to [Tilo Spannagel](https://github.com/tilosp), the playbook can now enable IPv6 for container networks for various components (roles) via [the `devture_systemd_docker_base_ipv6_enabled` variable](https://github.com/devture/com.devture.ansible.role.systemd_docker_base/blob/c11a526bb8e318b42eb52055056377bb31154f13/defaults/main.yml#L14-L31).
-
-It should be noted that:
-
-- Matrix roles (`roles/custom/matrix-*`) respect this variable, but external roles (those defined in `requirements.yml` and installed via `just roles`) do not respect it yet. Additional work is necessary
-- changing the variable subsequently may not change existing container networks. Refer to [these instructions](https://github.com/devture/com.devture.ansible.role.systemd_docker_base/blob/c11a526bb8e318b42eb52055056377bb31154f13/defaults/main.yml#L26-L30)
-- this is all very new and untested
-
-## Pantalaimon support
-
-Thanks to [Julian Foad](https://matrix.to/#/@julian:foad.me.uk), the playbook can now install the [Pantalaimon](https://github.com/matrix-org/pantalaimon) E2EE aware proxy daemon for you. It's already possible to integrate it with [Draupnir](docs/configuring-playbook-bot-draupnir.md) to allow it to work in E2EE rooms - see our Draupnir docs for details.
-
-See our [Setting up Pantalaimon](docs/configuring-playbook-pantalaimon.md) documentation to get started.
-
-
-# 2024-03-05
-
-## Support for Draupnir-for-all
-
-Thanks to [FSG-Cat](https://github.com/FSG-Cat), the playbook can now install [Draupnir for all](./docs/configuring-playbook-appservice-draupnir-for-all.md) (aka multi-instance Draupnir running in appservice mode).
-
-This is an alternative to [running Draupnir in bot mode](./docs/configuring-playbook-bot-draupnir.md), which is still supported by the playbook.
-
-The documentation page for [Draupnir for all](./docs/configuring-playbook-appservice-draupnir-for-all.md) contains more information on how to install it.
-
-
-# 2024-02-19
-
-## Support for bridging to Facebook/Messenger via the new mautrix-meta bridge
-
-The [mautrix-facebook](./docs/configuring-playbook-bridge-mautrix-facebook.md) and [mautrix-instagram](./docs/configuring-playbook-bridge-mautrix-instagram.md) bridges are being [superseded by a new bridge](https://github.com/mautrix/facebook/issues/332) - the [mautrix-meta](https://github.com/mautrix/meta) bridge.
-
-The playbook now supports the new mautrix-meta bridge - a single bridge, which can run in different modes and bridge to Messenger (via [Facebook](https://facebook.com/), Facebook over [Tor](https://www.torproject.org/) or via [Messenger](https://messenger.com/)) and [Instagram](https://instagram.com/). The playbook makes this bridge available via 2 separate Ansible roles, allowing you to easily run 2 instances of mautrix-meta, for bridging to both services at the same time.
-
-If you're using mautrix-facebook or mautrix-instagram right now, **you can still continue using the old bridges, but may wish to change to the new bridge implementations**. See:
-
-- [Setting up Instagram bridging via Mautrix Meta](docs/configuring-playbook-bridge-mautrix-meta-instagram.md)
-
-- [Setting up Messenger bridging via Mautrix Meta](docs/configuring-playbook-bridge-mautrix-meta-messenger.md)
-
-The documentation pages contain more information on how to migrate.
-
-
-# 2024-02-14
-
-## Much larger Synapse caches and cache auto-tuning enabled by default
-
-Thanks to [FSG-Cat](https://github.com/FSG-Cat), the playbook now uses much larger caches and enables Synapse's [cache auto-tuning functionality](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#caches-and-associated-values).
-This work and the default values used by the playbook are inspired by [Tom Foster](https://github.com/tcpipuk)'s [Synapse homeserver guide](https://tcpipuk.github.io/synapse/deployment/synapse.html).
-
-The playbook has always used a very conservative cache factor (`matrix_synapse_caches_global_factor`) value of `0.5`, which may be OK for small and underactive deployments, but is not ideal for larger servers. Paradoxically, a small global cache factor value [does not necessarily decrease RAM usage as a whole](https://github.com/matrix-org/synapse/issues/3939).
-
-The playbook now uses **a 20x larger cache factor** (currently `10`), adjusts a few other cache-related variables, and **enables cache auto-tuning** via the following variables:
-
-- `matrix_synapse_cache_autotuning_max_cache_memory_usage` - defaults to 1/8 of total RAM with a cap of 2GB; values are specified in bytes
-- `matrix_synapse_cache_autotuning_target_cache_memory_usage` - defaults to 1/16 of total RAM with a cap of 1GB; values are specified in bytes
-- `matrix_synapse_cache_autotuning_min_cache_ttl` - defaults to `30s`
-
-These values should be good defaults for most servers, but may change over time as we experiment further.
-
-Refer to our new [Tuning caches and cache autotuning](docs/maintenance-synapse.md#tuning-caches-and-cache-autotuning) documentation section for more details.
-
-
-# 2024-01-31
-
-## (Backward-compatibility break) Minor changes necessary for some people serving a static website at the base domain
-
-This only affects people who are [Serving a static website at the base domain](./docs/configuring-playbook-base-domain-serving.md#serving-a-static-website-at-the-base-domain), but not managing its `index.html` through the playbook.
-
-That is, for people who have `matrix_static_files_file_index_html_enabled: false` in their `vars.yml` configuration, the playbook has a new default behavior. Since the playbook is not managing the `index.html` file, it will default to a more sensible way of handling the base domain  - redirecting `https://DOMAIN/` to `https://matrix.DOMAIN/`, instead of serving a 404 page.
-
-If you are managing your static website by yourself (by dropping files into `/matrix/static-files/public` somehow), then you probably don't wish for such redirection to happen. You can disable it by adding `matrix_static_files_container_labels_base_domain_root_path_redirection_enabled: false` to your `vars.yml` configuration file.
-
-
-# 2024-01-20
-
-## Support for more efficient (specialized) Synapse workers
-
-Thanks to [Charles Wright](https://github.com/cvwright) from [FUTO](https://www.futo.org/), the creators of the [Circles app](https://circu.li/), the playbook has [received support](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3100) for load-balancing the Synapse workload via [specialized workers](./docs/configuring-playbook-synapse.md#specialized-workers) which are supposed to work better than our old [generic workers](./docs/configuring-playbook-synapse.md#generic-workers) implementation.
-
-For now, playbook defaults remain unchanged and the `one-of-each` [workers preset](./docs/configuring-playbook-synapse.md#worker-presets) continues being the default. However, the default may change in the future. If you'd like to remain on this preset even if/when the defaults change, consider explicitly adding `matrix_synapse_workers_preset: one-of-each` to your `vars.yml` configuration.
-
-Our specialized workers setup is based on recommendations found in [Tom Foster](https://github.com/tcpipuk)'s [Synapse homeserver guide](https://tcpipuk.github.io/synapse/index.html). What's special about our new setup is that we try to parse information out of the request (who the user is; which room is being operated on) and try to forward similar requests to the same worker. As an example, this means that once a worker caches some room information, subsequent requests for the same room will be routed to the same worker (which supposedly still has the room's state cached).
-
-To get started, refer to our [Specialized workers](./docs/configuring-playbook-synapse.md#specialized-workers) documentation section.
-
-
-# 2024-01-17
-
-## Switching to Element's AGPLv3-licensed Synapse release
-
-A few months ago, the [Element](https://element.io/) company has [announced](https://element.io/blog/element-to-adopt-agplv3/) that their work on the Synapse homeserver would no longer be available under the permissive [Apache-2.0 license](https://www.apache.org/licenses/LICENSE-2.0), but only under:
-
-- the [AGPLv3](https://www.gnu.org/licenses/agpl-3.0.en.html) free-software license - the same license that this Ansible playbook has always used
-- a proprietary license, for those wishing for Element to [sell them an exception](https://gnu.org/philosophy/selling-exceptions.html) to the AGPLv3 license
-
-You can also learn more in [this post](https://matrix.org/blog/2023/11/06/future-of-synapse-dendrite/) by the Matrix Foundation.
-
-The change has [already happened](https://element.io/blog/synapse-now-lives-at-github-com-element-hq-synapse/) and the first Synapse release under the new license is here: [v1.99.0](https://github.com/element-hq/synapse/releases/tag/v1.99.0).
-
-There is no up-to-date alternative Synapse fork right now and this free-software (AGPLv3-licensed) playbook is definitely not against free-software licenses, so we are now switching to the Element-maintained Synapse release.
-
-**What does this mean to you?**
-
-For most home users, it doesn't mean anything. Your installation will continue working as it should and you don't need to do anything.
-
-For people building commercial products on top of Synapse, they may have to either buy a license exception from Element (from what we hear, the fee depends on the number of monthly-active users on your instance) or they may need to release all related code as free-software (which is what we've been doing at [etke.cc](https://etke.cc/) ([here](https://gitlab.com/etke.cc)) all along).
-
-We're no lawyers and this changelog entry does not aim to give you the best legal advice, so please research on your own!
-
-If you'd like to continue using the old Apache-2.0-licensed Synapse (for a while longer anyway), the playbook makes it possible by intruducing a new Ansible variable. You can do it like this:
-
-```yaml
-# Switch the organization that Synapse container images (or source code for self-building) are pulled from.
-# Note: the new default value is `element-hq/synapse`.
-matrix_synapse_github_org_and_repo: matrix-org/synapse
-
-# Pin the Synapse version to the last one (v1.98.0) released by the Matrix Foundation
-# under the old permissive Apache-2.0 license.
-matrix_synapse_version: v1.98.0
-```
-
-Notes:
-
-- if you had already upgraded Synapse to `v1.99.0` by running this playbook, you will still be able to downgrade to `v1.98.0`, because both releases use the same database schema version (`SCHEMA_COMPAT_VERSION = 83` - see [here for v1.98.0](https://github.com/element-hq/synapse/blob/v1.98.0/synapse/storage/schema/__init__.py#L131-L134) and [here for v1.99.0](https://github.com/element-hq/synapse/blob/v1.99.0/synapse/storage/schema/__init__.py#L137-L140)). More details on Synapse's database schema are available [here](https://element-hq.github.io/synapse/develop/development/database_schema.html). It appears that there are no new database migrations introduced in `v1.99.0`, so going back to the older release is possible. This is not guaranteed to hold true for future Synapse releases, so if you're seeing this early-enough, consider pinning the version and organization before re-running the playbook and getting upgraded to the latest version
-
-- running an outdated homeserver exposes you to security issues and incompatibilities. Only consider doing this as a short-term solution.
-
-# 2024-01-16
-
-## `Draupnir` has been relicensed to AFL-3.0
-
-As of [#204](https://github.com/the-draupnir-project/Draupnir/pull/204) Draupnir changed its licence to AFL-3.0 from the CSL licence. This change affects playbook users who could not run Draupnir under the old license restrictions. The new license is considerably less restrictive and is OSI approved. Draupnir version v1.86.0 and later are covered by this license change.
-
-# 2024-01-15
-
-## Goodbye, `matrix-nginx-proxy` 🪦
-
-**TLDR**: All traces of the `matrix-nginx-proxy` reverse-proxy component are now gone. This brought about many other internal changes (and security improvements), so setups may need minor adjustments or suffer some (temporary) breakage. People who have been on the Traefik-native setup may upgrade without much issues. Those running their own Traefik instance may need minor changes. People who have been postponing the migration away from `matrix-nginx-proxy` (for more than a year already!) will now finally need to do something about it.
-
-### Backstory on `matrix-nginx-proxy`
-
-We gather here today to celebrate the loss of a once-beloved component in our stack - `matrix-nginx-proxy`. It's been our [nginx](https://nginx.org/)-based reverse-proxy of choice since the [first commit](https://github.com/spantaleev/matrix-docker-ansible-deploy/tree/87f5883f2455fb115457b65f267f17de305c053c) of this playbook, 7 years ago.
-
-For 6 years, `matrix-nginx-proxy` has been the front-most reverse-proxy in our setup (doing SSL termination, etc.). After [transitioning to Traefik last year](#traefik-is-the-default-reverse-proxy-now), `matrix-nginx-proxy` took a step back. Nevertheless, since it was so ingrained into the playbook, it still remained in use - even if only internally. Despite our warnings of its imminent death, many of you have indubitably continued to use it instead of Traefik. Its suffering continued for too long, because it served many different purposes and massive effort was required to transition them to others.
-
-To us, `matrix-nginx-proxy` was:
-
-- an [nginx](https://nginx.org/)-based reverse-proxy
-- an Ansible role organizing the work of [certbot](https://certbot.eff.org/) - retrieving free [Let's Encrypt](https://letsencrypt.org/) SSL certificates for `matrix-nginx-proxy` and for the [Coturn TURN server](./docs/configuring-playbook-turn.md)
-- a central component for reverse-proxying to the [long list of services](./docs/configuring-playbook.md) supported by the playbook. As such, it became a dependency that all these services had to inject themselves into during runtime
-- an intermediary through which addons (bridges, bots) communicated with the homeserver. Going through an intermediary (instead of directly talking to the homeserver) is useful when certain components (like [matrix-media-repo](./docs/configuring-playbook-matrix-media-repo.md) or [matrix-corporal](./docs/configuring-playbook-matrix-corporal.md)) are enabled, because it lets these services "steal routes" from the homeserver
-- a webserver for serving the `/.well-known/matrix` static files (generated by the `matrix-base` role until now)
-- a webserver [serving your base domain](./docs/configuring-playbook-base-domain-serving.md) (and also generating the `index.html` page for it)
-- a central component providing global [HTTP Basic Auth](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication) password-protection for all `/metrics` endpoints when metrics were exposed publicly for consumption from a remote Prometheus server
-
-Talk about a jack of all trades! The [UNIX philosophy](https://en.wikipedia.org/wiki/Unix_philosophy) (and Docker container philosophy) of "do one thing and do it well" had been severely violated for too long.
-
-On a related note, we also had a large chain of reverse-proxies in the mix.
-In the worst case, it was something like this: (Traefik -> `matrix-nginx-proxy:8080` -> `matrix-nginx-proxy:12080` -> `matrix-synapse-reverse-proxy-companion:8008` -> `matrix-synapse:8008`).
-
-Due to complexity and the playbook's flexibility (trying to accommodate a mix of tens of components), many layers of indirection were necessary. We do like reverse-proxies, but.. not quite enough to enjoy going through a chain of ~4 of them before reaching the target service.
-
-After **a ton of work** in the last weeks (200+ commits, which changed 467 files - 8684 insertions and 8913 deletions), **we're finally saying goodbye** to `matrix-nginx-proxy`.
-
-
-### Going Traefik-native and cutting out all middlemen
-
-In our new setup, you'll see the bare minimum number of reverse-proxies.
-
-In most cases, there's only Traefik and all services being registered directly with it. When [Synapse workers](./docs/configuring-playbook-synapse.md#load-balancing-with-workers) are enabled, `matrix-synapse-reverse-proxy-companion` remains as an extra reverse-proxy that requests go through (for load-balancing to the correct Synapse worker), but in all other cases services are exposed directly.
-
-This reduces "network" hops (improving performance) and also decreases the number of components (containers).
-Each Ansible role in our setup is now independent and doesn't need to interact with other roles during runtime.
-
-
-### Traefik now has an extra job
-
-Previously, **Traefik had a single purpose** - being the main reverse-proxy. It was either front-most (terminating SSL, etc.) or you were [fronting Traefik with your own other reverse-proxy](./docs/configuring-playbook-own-webserver.md#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy). In any case - it had this central (yet decentralized) job.
-
-Now, **Traefik has one more role** - it serves as an intermediary which allows addon services (bridges, bots, etc.) to communicate with the homeserver. As mentioned above, such an intermediary service is not strictly necessary in all kinds of setups, but more complex setups (including [matrix-media-repo](./docs/configuring-playbook-matrix-media-repo.md) or [matrix-corporal](./docs/configuring-playbook-matrix-corporal.md)) benefit from it.
-
-To perform this new role, Traefik now has a new internal [entrypoint](https://doc.traefik.io/traefik/routing/entrypoints/) called `matrix-internal-matrix-client-api`. All homeservers (Conduit, Dendrite, Synapse and even `matrix-synapse-reverse-proxy-companion`) and homeserver-related core services ([matrix-media-repo](./docs/configuring-playbook-matrix-media-repo.md), [matrix-corporal](./docs/configuring-playbook-matrix-corporal.md) and potentially others) register their routes (using [container labels](https://docs.docker.com/config/labels-custom-metadata/)) not only on the public entrypoints (`web-secure`, `matrix-federation`), but also on this new internal entrypoint.
-
-Doing so, services can contact Traefik on this entrypoint's dedicated port (the URL defaults to `http://matrix-traefik:8008`) and reach the homeserver Client-Server API as they expect. Internally, Traefik takes care of the routing to the correct service.
-
-We've also considered keeping it simple and having services talk to the homeserver over the public internet (e.g. `https://matrix.DOMAIN`) thus reusing all existing Traefik routing labels. In this scenario, performance was incredibly poor (e.g. 70 rps, instead of 1400 rps) due to TLS and networking overhead. The need for fast internal communication (via the new internal non-TLS-enabled Traefik entrypoint) is definitely there. In our benchmarks, Traefik even proved more efficient than nginx at doing this: ~1200 rps for Traefik compared to ~900 rps for nginx (out of ~1400 rps when talking to the Synapse homeserver directly).
-
-Traefik serving this second purpose has a few downsides:
-
-- Traefik becomes a runtime dependency for all homeserver-dependant container services
-- all homeserver-dependant services now need to be connected to the `traefik` container network, even if they don't need public internet exposure
-
-Despite these downsides (which the playbook manages automatically), we believe it's still a good compromise given the amount of complexity it eliminates and the performance benefits it yields. One alternative we've [considered](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3045#issuecomment-1867327001) was adding a new intermediary service (e.g. `matrix-homeserver-proxy` powered by nginx), but this both had much higher complexity (one more component in the mix; duplication of effort to produce nginx-compatible route definitions for it) and slightly worse performance (see above).
-
-People running the default Traefik setup do not need to do anything to make Traefik take on this extra job. Your Traefik configuration will be updated automatically.
-
-**People runnning their own Traefik reverse-proxy need to do [minor adjustments](#people-managing-their-own-traefik-instance-need-to-do-minor-changes)**, as described in the section below.
-
-You may disable Traefik acting as an intermediary by explicitly setting `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_enabled` to `false`. Services would then be configured to talk to the homeserver directly, giving you a slight performance boost and a "simpler" Traefik setup. However, such a configuration is less tested and will cause troubles, especially if you enable more services (like `matrix-media-repo`, etc.) in the future. As such, it's not recommended.
-
-
-### People managing their own Traefik instance need to do minor changes
-
-This section is for people [managing their own Traefik instance on the Matrix server](./docs/configuring-playbook-own-webserver.md#traefik-managed-by-you). Those [using Traefik managed by the playbook](./docs/configuring-playbook-own-webserver.md#traefik-managed-by-the-playbook) don't need to do any changes.
-
-Because [Traefik has an extra job now](#traefik-now-has-an-extra-job), you need to adapt your configuration to add the additional `matrix-internal-matrix-client-api` entrypoint and potentially configure the `matrix_playbook_reverse_proxy_container_network` variable. See the [Traefik managed by you](./docs/configuring-playbook-own-webserver.md#traefik-managed-by-you) documentation section for more details.
-
-
-### People fronting Traefik with another reverse proxy need to do minor changes
-
-We've already previously mentioned that you need to do some minor [configuration changes related to `traefik_additional_entrypoints_auto`](#backward-compatibility-configuration-changes-required-for-people-fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy).
-
-If you don't do these changes (switching from `traefik_additional_entrypoints_auto` to multiple other variables), your Traefik setup will not automatically receive the new `matrix-internal-matrix-client-api` Traefik entrypoint and Traefik would not be able to perform [its new duty of connecting addons with the homeserver](#traefik-now-has-an-extra-job).
-
-
-### Supported reverse proxy types are now fewer
-
-This section is for people using a more custom reverse-proxy setup - those having `matrix_playbook_reverse_proxy_type` set to a value different than the default (`playbook-managed-traefik`).
-
-Previously, we allowed you to set `matrix_playbook_reverse_proxy_type` to 7 different values to accommodate various reverse-proxy setups.
-
-The complexity of this is too high, so we only support 3 values right now:
-
-- (the default) `playbook-managed-traefik`, when you're [using Traefik managed by the playbook](./docs/configuring-playbook-own-webserver.md#traefik-managed-by-the-playbook)
-- `other-traefik-container`, when you're [managing your own Traefik instance on the Matrix server](./docs/configuring-playbook-own-webserver.md#traefik-managed-by-you)
-- `none`, when you wish for [no reverse-proxy integration to be done at all](./docs/configuring-playbook-own-webserver.md#using-no-reverse-proxy-on-the-matrix-side-at-all)
-
-The `none` value is not recommended and may not work adequately, due to lack of testing and [Traefik's new responsibilities](#traefik-now-has-an-extra-job) in our setup.
-
-**Previous values that are now gone** (and the playbook would report them as such) are: `playbook-managed-nginx`, `other-nginx-non-container`, `other-on-same-host` and `other-on-another-host`.
-
-If you were using these values as a way to stay away from Traefik, you now have 2 options:
-
-- (recommended) [Fronting Traefik with another reverse-proxy](./docs/configuring-playbook-own-webserver.md#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy)
-- (not recommended) [Using no reverse-proxy on the Matrix side at all](./docs/configuring-playbook-own-webserver.md#using-no-reverse-proxy-on-the-matrix-side-at-all) and reverse-proxying to each and every service manually
-
-
-### Container networking changes
-
-Now that `matrix-nginx-proxy` is not in the mix, it became easier to clear out some other long-overdue technical debt.
-
-Since the very beginning of this playbook, all playbook services were connected to a single (shared) `matrix` container network. Later on, some additional container networks appeared, but most services (database, etc.) still remained in the `matrix` container network.  This meant that any random container in this network could try to talk (or attack) the Postgres database operating in the same `matrix` network.
-
-Moving components (especially the database) into other container networks was difficult - it required changes to many other components to ensure correct connectivity.
-
-All the hard work has been done now. We've added much more isolation between services by splitting them up into separate networks (`matrix-homeserver`, `matrix-addons`, `matrix-monitoring`, `matrix-exim-relay`, etc). Components are only joined to the networks they need and should (for the most part) not be able to access unrelated things.
-
-Carrying out these container networking changes necessitated modifying many components, so **we're hoping not too many bugs were introduced in the process**.
-
-We've refrained from creating too many container networks (e.g. one for each component), to avoid exhausting Docker's default network pool and contaminating the container networks list too much.
-
-
-### Metrics exposure changes
-
-This section is for people who are exposing monitoring metrics publicly, to be consumed by an external Prometheus server.
-
-Previously, `matrix-nginx-proxy` was potentially password-protecting all `/metrics/*` endpoints with the same username and password (specified as plain-text in your `vars.yml` configuration file).
-
-From now on, there are new variables for doing roughly the same - `matrix_metrics_exposure_enabled`, `matrix_metrics_exposure_http_basic_auth_enabled` and `matrix_metrics_exposure_http_basic_auth_users`. See the [Prometheus & Grafana](./docs/configuring-playbook-prometheus-grafana.md) docs page for details.
-
-`matrix-nginx-proxy` is not acting as a "global guardian" anymore. Now, each role provides its own metrics exposure and protection by registering with Traefik. Nevertheless, all roles are wired (via playbook configuration in `group_vars/matrix_servers`) to obey these new `matrix_metrics_exposure_*` variables. We've eliminated the centralization, but have kept the ease of use. Now, you can also do per-service password-protection (with different credentials), should you need to do that for some reason.
-
-The playbook will tell you about all variables that you need to migrate during runtime, so rest assured - you shouldn't be able to miss anything!
-
-
-### Matrix static files
-
-As mentioned above, static files like `/.well-known/matrix/*` or your base domain's `index.html` file (when [serving the base domain via the Matrix server](./docs/configuring-playbook-base-domain-serving.md) was enabled) were generated by the `matrix-base` or `matrix-nginx-proxy` roles and put into a `/matrix/static-files` directory on the server. Then `matrix-nginx-proxy` was serving all these static files.
-
-All of this has been extracted into a new `matrix-static-files` Ansible role that's part of the playbook. The static files generated by this new role still live at roughly the same place (`/matrix/static-files/public` directory, instead of `/matrix/static-files`).
-
-The playbook will migrate and update the `/.well-known/matrix/*` files automatically but not your own files in `nginx-proxy/data/matrix-domain/` you will need to back these up yourself otherwise they will be lost. It will also warn you about usage of old variable names, so you can adapt to the new names.
-
-
-### A note on performance
-
-Some of you have been voicing their concerns (for a long time) about Traefik being too slow and nginx being better.
-
-Some online benchmarks support this by demonstrating slightly higher SSL-termination performance in favor of nginx. The upcoming Traefik v3 release is [said to](https://medium.com/beyn-technology/is-nginx-dead-is-traefik-v3-20-faster-than-traefik-v2-f28ffb7eed3e) improve Traefik's SSL performance by some 20%, but that still ends up being somewhat slower than nginx.
-
-We believe that using Traefik provides way too many benefits to worry about this minor performance impairment.
-
-The heaviest part of running a Matrix homeserver is all the slow and potentially inefficient things the homeserver (e.g. Synapse) is doing. These things affect performance much more than whatever reverse-proxy is in front. Your server will die the same way by joining the famously large **Matrix HQ** room, no matter which reverse-proxy you put in front.
-
-Even our previously mentioned benchmarks (yielding ~1300 rps) are synthetic - hitting a useless `/_matrix/client/versions` endpoint. Real-use does much more than this.
-
-If this is still not convincing enough for you and you want the best possible performance, consider [Fronting Traefik with another reverse-proxy](./docs/configuring-playbook-own-webserver.md#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) (thus having the slowest part - SSL termination - happen elsewhere) or [Using no reverse-proxy on the Matrix side at all](./docs/configuring-playbook-own-webserver.md#using-no-reverse-proxy-on-the-matrix-side-at-all). The playbook will not get in your way of doing that, but these options may make your life much harder. Performance comes at a cost, after all.
-
-
-### Migration procedure
-
-The updated playbook will automatically perform some migration tasks for you:
-
-1. It will stop and remove the `matrix-nginx-proxy` systemd service and container for you. This behavior cannot be disabled. It's essential that this service gets stopped, because it remaining running (and having container labels) may confuse Traefik as to where to route HTTP requests.
-
-2. It will delete the `/matrix/nginx-proxy` directory and all files within it. You can disable this behavior by adding `matrix_playbook_migration_matrix_nginx_proxy_uninstallation_enabled: false` to your `vars.yml` configuration file. Doing so will leave its data around.
-
-3. It will delete the `/matrix/ssl` directory and all files within it. You can disable this behavior by adding `matrix_playbook_migration_matrix_ssl_uninstallation_enabled: false` to your `vars.yml` configuration file. If you have some important certificates there for some reason, take them out or temporarily disable removal of these files until you do.
-
-4. It will tell you about all variables (`matrix_nginx_proxy_*` and many others - even from other roles) that have changed during this large nginx-elimination upgrade. You can disable this behavior by adding `matrix_playbook_migration_matrix_nginx_proxy_elimination_variable_transition_checks_enabled: false` to your `vars.yml` configuration file.
-
-5. It will tell you about any leftover `matrix_nginx_proxy_*` variables in your `vars.yml` file. You can disable this behavior by adding `matrix_playbook_migration_matrix_nginx_proxy_leftover_variable_validation_checks_enabled: false` to your `vars.yml` configuration file.
-
-6. It will tell you about any leftover `matrix_ssl_*` variables in your `vars.yml` file. You can disable this behavior by adding `matrix_playbook_migration_matrix_ssl_leftover_variable_checks_enabled: false` to your `vars.yml` configuration file.
-
-We don't recommend changing these variables and suppressing warnings, unless you know what you're doing.
-
-**Most people should just upgrade as per-normal**, bearing in mind that a lot has changed and some issues may arise.
-The playbook would guide you through renamed variables automatically.
-
-
-### Conclusion
-
-Thousands of lines of code were changed across hundreds of files.
-All addons (bridges, bots) were rewired in terms of container networking and in terms of how they reach the homeserver.
-
-I don't actively use all the ~100 components offered by the playbook (no one does), nor do I operate servers exercising all edge-cases. As such, issues may arise. Please have patience and report (or try to fix) these issues!
-
-
-# 2024-01-14
-
-## (Backward Compatibility) Configuration changes required for people fronting the integrated reverse-proxy webserver with another reverse-proxy
-
-If you're on the default setup (using the Traefik reverse-proxy as installed by the playbook), you don't need to do anything.
-
-People who are [Fronting the integrated Traefik reverse-proxy webserver with another reverse-proxy](./docs/configuring-playbook-own-webserver.md#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy), as per our previous instructions are redefining `traefik_additional_entrypoints_auto` in their `vars.yml` configuration.
-
-Such a full variable redefinion is intrustive, because it prevents the playbook from injecting additional entrypoints into the Traefik webserver. In the future, the playbook may have a need to do so.
-
-For this reason, we no longer recommend completely redefining `traefik_additional_entrypoints_auto`.
-The playbook now defines [various `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_*` variables in the `defaults/main.yml` file](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/roles/custom/matrix-base/defaults/main.yml) of the `matrix-base` role which can be used as a safer alternative to `traefik_additional_entrypoints_auto`.
-
-Adapt your configuration as seen below:
-
-```diff
--traefik_additional_entrypoints_auto:
--  - name: matrix-federation
--    port: 8449
--    host_bind_port: '127.0.0.1:8449'
--    config: {}
--    # If your reverse-proxy runs on another machine, remove the config above and use this config instead:
--    # config:
--    #   forwardedHeaders:
--    #     insecure: true
--    #     # trustedIPs: ['IP-ADDRESS-OF-YOUR-REVERSE-PROXY']
-+# Uncomment and tweak the variable below if the name of your federation entrypoint is different
-+# than the default value (matrix-federation).
-+# matrix_federation_traefik_entrypoint: matrix-federation
-+
-+# Uncomment and tweak the variable below if you really wish to change the internal port number
-+# that the federation endpoint uses. Changing it is generally not necessary.
-+# Usually, changing `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port` below is enough.
-+#matrix_playbook_public_matrix_federation_api_traefik_entrypoint_port: 8449
-+
-+matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port: 127.0.0.1:8449
-+
-+# Adapt the variable below based on where your reverse-proxy runs:
-+# - if it's on the Matrix server: keep `forwardedHeaders` and `insecure: true` as is
-+# - if it's on another machine: remove `forwardedHeaders` and `insecure: true` and enable/configure `trustedIPs`
-+matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_custom:
-+  forwardedHeaders:
-+    insecure: true
-+  # trustedIPs: ['IP-ADDRESS-OF-YOUR-REVERSE-PROXY']
-```
-
-Also, feel free to read the [Fronting the integrated Traefik reverse-proxy webserver with another reverse-proxy](./docs/configuring-playbook-own-webserver.md#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) documentation section again for additional details.
-
-
-# 2024-01-13
-
-## matrix-reminder-bot update with more secure (backward-incompatible) default settings
-
-**TLDR**: your updated (to [v0.3.0](https://github.com/anoadragon453/matrix-reminder-bot/releases/tag/v0.3.0)) [matrix-reminder-bot](./docs/configuring-playbook-bot-matrix-reminder-bot.md) is now more secure. By default, like other bridges/bots managed by the playbook, it will only provide its services to users of your own server (not to anyone, even across the Matrix Federation). If that's fine, there's nothing you need to do.
-
-Maintenance of [matrix-reminder-bot](./docs/configuring-playbook-bot-matrix-reminder-bot.md) has been picked up by [Kim Brose](https://github.com/HarHarLinks) and [@svierne](https://github.com/svierne).
-
-Thanks to them, a new [v0.3.0](https://github.com/anoadragon453/matrix-reminder-bot/releases/tag/v0.3.0) release is out. The new version is now available for the ARM64 architecture, so playbook users on this architecture will no longer need to wait for [self-building](./docs/self-building.md) to happen.
-
-The new version also comes with new `allowlist` and `blocklist` settings, which make it possible to restrict who can use the bot. Previously anyone, even across the Matrix Federation could talk to it and schedule reminders.
-
-The playbook defaults all bridges and bots (where possible) to only be exposed to users of the current homeserver, not users across federation.
-Thanks to the new version of this bot making such a restriction possible, we're now making use of it. The playbook (via its `group_vars/matrix_servers` file) automatically enables the `allowlist` (`matrix_bot_matrix_reminder_bot_allowlist_enabled: true`) and configures it in such a way (`matrix_bot_matrix_reminder_bot_allowlist_regexes_auto`) so as to restrict the bot to your homeserver's users.
-
-If you need **to undo or tweak these security improvements**, you can change your `vars.yml` file to:
-
-- disable the allowlist (`matrix_bot_matrix_reminder_bot_allowlist_enabled: false`), making the bot allow usage by anyone, anywhere
-
-- inject additional allowed servers or users by adding **additional** (on top of the default allowlist in `matrix_bot_matrix_reminder_bot_allowlist_regexes_auto`) custom regexes in the `matrix_bot_matrix_reminder_bot_allowlist_regexes_custom` list variable (see the [syntax reference](https://github.com/anoadragon453/matrix-reminder-bot/blob/1e910c0aa3469d280d93ee7e6c6d577227a3460c/sample.config.yaml#L43-L49))
-
-- override the default allowlist (in the `group_vars/matrix_servers` file) by redefining `matrix_bot_matrix_reminder_bot_allowlist_regexes_auto`
-
-
-# 2024-01-05
-
-## matrix-mailer has been replaced by the exim-relay external role
-
-We're continuing our effort to make [the playbook use external roles for some things](#the-playbook-now-uses-external-roles-for-some-things), so as to avoid doing everything ourselves and to facilitate code re-use.
-
-The `matrix-mailer` role has been moved to its own repository ([ansible-role-exim-relay](https://github.com/mother-of-all-self-hosting/ansible-role-exim-relay)) that this playbook now includes.
-
-To migrate:
-
-- pull the playbook changes, as usual
-- update your roles (run `just roles` or `make roles`)
-- update your `vars.yml`, renaming `matrix_mailer`-prefixed variables to `exim_relay`-prefixed ones (e.g. `matrix_mailer_sender_address` -> `exim_relay_sender_address`). If you find none, it means you're using the default configuration and your migraiton job is even simpler.
-- re-run the playbook (`install-all` or `setup-all`)
-
-The playbook will take care of stopping the old `matrix-mailer` systemd service, relocating its directory and restarting it under the new name (`matrix-exim-relay.service`).
-
-
-# 2024-01-02
-
-## mautrix-signal now powered by the new Go-based bridge
-
-The old Python-based [mautrix-signal](https://github.com/mautrix/signal) bridge is no longer maintained upstream. It's also known to have issues linking new devices.
-
-It seems like the path forward is to switch to the new mautrix-signal bridge written in Golang, which we did thanks to [PR #3031](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3041) by [Pierre 'McFly' Marty](https://github.com/pm-McFly).
-
-The playbook should **automatically migrate your mautrix-signal installation to the new bridge code**.
-You will **need to relink all your devices** to continue your bridged conversations.
-
-
 # 2023-10-23
 
 ## Enabling `allow_public_rooms_over_federation` by default for Synapse
@@ -704,9 +17,9 @@ The **historical reasoning** behind this change is as follows:
 
 - `allow_public_rooms_over_federation` seems to have been enabled by default for Synapse until v1.7.0 (~2019), just like we believe it should be for a globally-federating network - rooms should be joinable and discoverable across federation.
 
-- In Synapse v1.7.0 (~2019), `allow_public_rooms_over_federation` [got disabled](https://github.com/element-hq/synapse/blob/e9069c9f919685606506f04527332e83fbfa44d9/docs/upgrade.md?plain=1#L1877-L1891) by default in a [security-by-obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity) workaround for misconfigured servers. See the [Avoiding unwelcome visitors on private Matrix servers](https://matrix.org/blog/2019/11/09/avoiding-unwelcome-visitors-on-private-matrix-servers/) `matrix.org` blog article. We believe that people wishing for a truly private server, should [disable federation](docs/configuring-playbook-federation.md#disabling-federation), instead of having a fully-federating server and trying to hide its public rooms. We also provide other workarounds below. We (and the Synapse team, obviously) believe that Matrix should federate by default, so federating the public room list seems to make sense.
+- In Synapse v1.7.0 (~2019), `allow_public_rooms_over_federation` [got disabled](https://github.com/matrix-org/synapse/blob/e9069c9f919685606506f04527332e83fbfa44d9/docs/upgrade.md?plain=1#L1877-L1891) by default in a [security-by-obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity) workaround for misconfigured servers. See the [Avoiding unwelcome visitors on private Matrix servers](https://matrix.org/blog/2019/11/09/avoiding-unwelcome-visitors-on-private-matrix-servers/) `matrix.org` blog article. We believe that people wishing for a truly private server, should [disable federation](docs/configuring-playbook-federation.md#disabling-federation), instead of having a fully-federating server and trying to hide its public rooms. We also provide other workarounds below. We (and the Synapse team, obviously) believe that Matrix should federate by default, so federating the public room list seems to make sense.
 
-- [etke.cc](https://etke.cc/) has been developing the free-software [Matrix Rooms Search](https://github.com/etkecc/mrs) project for a while now. One public (demo) instance of it is hosted at [matrixrooms.info](https://matrixrooms.info/). This search engine tries to go through the Matrix federation and discover & index public rooms to allow people to find them. We believe it's vital for Matrix (and any chat or social network for that matter) to be more discoverable, so that people can find communities and others to talk to. Today (on 23rd of October 2023), `matrixrooms.info` is indexing `23066` Matrix servers. Of these, only `1567` servers (7%) are making their public rooms discoverable. Who knows what wonderful communities and rooms are available on these 93% other Matrix servers that are supposedly federating, but are still gate-keeping their public room list. Indubitably, many of these servers are hosted via matrix-docker-ansible-deploy, so we feel partially responsible for making Matrix federation less useful.
+- [etke.cc](https://etke.cc/) has been developing the free-software [Matrix Rooms Search](https://gitlab.com/etke.cc/mrs) project for a while now. One public (demo) instance of it is hosted at [matrixrooms.info](https://matrixrooms.info/). This search engine tries to go through the Matrix federation and discover & index public rooms to allow people to find them. We believe it's vital for Matrix (and any chat or social network for that matter) to be more discoverable, so that people can find communities and others to talk to. Today (on 23rd of October 2023), `matrixrooms.info` is indexing `23066` Matrix servers. Of these, only `1567` servers (7%) are making their public rooms discoverable. Who knows what wonderful communities and rooms are available on these 93% other Matrix servers that are supposedly federating, but are still gate-keeping their public room list. Indubitably, many of these servers are hosted via matrix-docker-ansible-deploy, so we feel partially responsible for making Matrix federation less useful.
 
 Here are **actions you may wish to take** as a result of this change:
 
@@ -723,11 +36,11 @@ Here are **actions you may wish to take** as a result of this change:
 
 The playbook has provided some hints about [Tuning PostgreSQL](docs/maintenance-postgres.md#tuning-postgresql) for quite a while now.
 
-From now on, the [Postgres Ansible role](https://github.com/mother-of-all-self-hosting/ansible-role-postgres) automatically tunes your Postgres configuration with the same [calculation logic](https://github.com/le0pard/pgtune/blob/master/src/features/configuration/configurationSlice.js) that powers https://pgtune.leopard.in.ua/.
+From now on, the [Postgres Ansible role](https://github.com/devture/com.devture.ansible.role.postgres) automatically tunes your Postgres configuration with the same [calculation logic](https://github.com/le0pard/pgtune/blob/master/src/features/configuration/configurationSlice.js) that powers https://pgtune.leopard.in.ua/.
 
 Our [Tuning PostgreSQL](docs/maintenance-postgres.md#tuning-postgresql) documentation page has details about how you can turn auto-tuning off or adjust the automatically-determined Postgres configuration parameters manually.
 
-People who [enable load-balancing with Synapse workers](docs/configuring-playbook-synapse.md#load-balancing-with-workers) no longer need to increase the maximum number of Postgres connections manually (previously done via `postgres_process_extra_arguments`). There's a new variable (`postgres_max_connections`) for controlling this number and the playbook automatically raises its value from `200` to `500` for setups which enable workers.
+People who [enable load-balancing with Synapse workers](docs/configuring-playbook-synapse.md#load-balancing-with-workers) no longer need to increase the maximum number of Postgres connections manually (previously done via `devture_postgres_process_extra_arguments`). There's a new variable (`devture_postgres_max_connections`) for controlling this number and the playbook automatically raises its value from `200` to `500` for setups which enable workers.
 
 
 # 2023-08-31
@@ -870,7 +183,7 @@ To get started, see our [Setting up Sliding Sync Proxy](docs/configuring-playboo
 
 ## The matrix-etherpad role lives independently now
 
-**TLDR**: the `matrix-etherpad` role is now included from [another repository](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad). Some variables have been renamed. All functionality remains intact.
+**TLDR**: the `matrix-etherpad` role is now included from [another repository](https://gitlab.com/etke.cc/roles/etherpad). Some variables have been renamed. All functionality remains intact.
 
 You need to **update your roles** (`just roles` or `make roles`) regardless of whether you're using Etherpad or not.
 
@@ -978,7 +291,7 @@ Additional details are available in the [Customizing templates](docs/configuring
 
 **TLDR**: the `matrix-redis` role is now included from another repository. Some variables have been renamed. All functionality remains intact.
 
-The `matrix-redis` role (which configures [Redis](https://redis.io/)) has been extracted from the playbook and now lives in its [own repository](https://github.com/mother-of-all-self-hosting/ansible-role-redis). This makes it possible to easily use it in other Ansible playbooks.
+The `matrix-redis` role (which configures [Redis](https://redis.io/)) has been extracted from the playbook and now lives in its [own repository](https://gitlab.com/etke.cc/roles/redis). This makes it possible to easily use it in other Ansible playbooks.
 
 You need to **update your roles** (`just roles` or `make roles`) regardless of whether you're enabling Ntfy or not. If you're making use of Ntfy via this playbook, you will need to update variable references in your `vars.yml` file (`matrix_redis_` -> `redis_`).
 
@@ -986,7 +299,7 @@ You need to **update your roles** (`just roles` or `make roles`) regardless of w
 
 **TLDR**: the `matrix-ntfy` role is now included from another repository. Some variables have been renamed. All functionality remains intact.
 
-The `matrix-ntfy` role (which configures [Ntfy](https://ntfy.sh/)) has been extracted from the playbook and now lives in its [own repository](https://github.com/mother-of-all-self-hosting/ansible-role-ntfy). This makes it possible to easily use it in other Ansible playbooks.
+The `matrix-ntfy` role (which configures [Ntfy](https://ntfy.sh/)) has been extracted from the playbook and now lives in its [own repository](https://gitlab.com/etke.cc/roles/ntfy). This makes it possible to easily use it in other Ansible playbooks.
 
 You need to **update your roles** (`just roles` or `make roles`) regardless of whether you're enabling Ntfy or not. If you're making use of Ntfy via this playbook, you will need to update variable references in your `vars.yml` file (`matrix_ntfy_` -> `ntfy_`).
 
@@ -997,7 +310,7 @@ You need to **update your roles** (`just roles` or `make roles`) regardless of w
 
 **TLDR**: the `matrix-grafana` role is now included from another repository. Some variables have been renamed. All functionality remains intact.
 
-The `matrix-grafana` role (which configures [Grafana](docs/configuring-playbook-prometheus-grafana.md)) has been extracted from the playbook and now lives in its [own repository](https://github.com/mother-of-all-self-hosting/ansible-role-grafana). This makes it possible to easily use it in other Ansible playbooks.
+The `matrix-grafana` role (which configures [Grafana](docs/configuring-playbook-prometheus-grafana.md)) has been extracted from the playbook and now lives in its [own repository](https://gitlab.com/etke.cc/roles/grafana). This makes it possible to easily use it in other Ansible playbooks.
 
 You need to **update your roles** (`just roles` or `make roles`) regardless of whether you're enabling Grafana or not. If you're making use of Grafana via this playbook, you will need to update variable references in your `vars.yml` file (`matrix_grafana_` -> `grafana_`).
 
@@ -1008,7 +321,7 @@ You need to **update your roles** (`just roles` or `make roles`) regardless of w
 
 **TLDR**: the `matrix-backup-borg` role is now included from another repository. Some variables have been renamed. All functionality remains intact.
 
-Thanks to [moan0s](https://github.com/moan0s), the `matrix-backup-borg` role (which configures [Borg backups](docs/configuring-playbook-backup-borg.md)) has been extracted from the playbook and now lives in its [own repository](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg). This makes it possible to easily use it in other Ansible playbooks and will become part of [nextcloud-docker-ansible-deploy](https://github.com/spantaleev/nextcloud-docker-ansible-deploy) soon.
+Thanks to [moan0s](https://github.com/moan0s), the `matrix-backup-borg` role (which configures [Borg backups](docs/configuring-playbook-backup-borg.md)) has been extracted from the playbook and now lives in its [own repository](https://gitlab.com/etke.cc/roles/backup_borg). This makes it possible to easily use it in other Ansible playbooks and will become part of [nextcloud-docker-ansible-deploy](https://github.com/spantaleev/nextcloud-docker-ansible-deploy) soon.
 
 You need to **update your roles** (`just roles` or `make roles`) regardless of whether you're enabling Borg backup functionality or not. If you're making use of Borg backups via this playbook, you will need to update variable references in your `vars.yml` file (`matrix_backup_borg_` -> `backup_borg_`).
 
@@ -1086,7 +399,7 @@ Unless we have some regression, **existing `matrix-nginx-proxy` users should be
 ```yaml
 matrix_playbook_reverse_proxy_type: playbook-managed-traefik
 
-traefik_config_certificatesResolvers_acme_email: YOUR_EMAIL_ADDRESS
+devture_traefik_config_certificatesResolvers_acme_email: YOUR_EMAIL_ADDRESS
 ```
 
 You may still need to keep certain old `matrix_nginx_proxy_*` variables (like `matrix_nginx_proxy_base_domain_serving_enabled`), even when using Traefik. For now, we recommend keeping all `matrix_nginx_proxy_*` variables just in case. In the future, reliance on `matrix-nginx-proxy` will be removed.
@@ -1113,7 +426,7 @@ As mentioned above, Traefik still reverse-proxies to some (most) services by goi
 As Traefik support becomes complete and proves to be stable for a while, especially as a playbook default, we will **most likely remove `matrix-nginx-proxy` completely**. It will likely be some months before this happens though. Keeping support for both Traefik and nginx in the playbook will be a burden, especially with most of us running Traefik in the future. The Traefik role should do everything nginx does in a better and cleaner way. Users who use their own `nginx` server on the Matrix server will be inconvenienced, as nothing will generate ready-to-include nginx configuration for them. Still, we hope it won't be too hard to migrate their setup to another way of doing things, like:
 
 - not using nginx anymore. A common reason for using nginx until now was that you were running other containers and you need your own nginx to reverse-proxy to all of them. Just switch them to Traefik as well.
-- running Traefik in local-only mode (`traefik_config_entrypoint_web_secure_enabled: false`) and using some nginx configuration which reverse-proxies to Traefik (we should introduce examples for this in `examples/nginx`).
+- running Traefik in local-only mode (`devture_traefik_config_entrypoint_web_secure_enabled: false`) and using some nginx configuration which reverse-proxies to Traefik (we should introduce examples for this in `examples/nginx`).
 
 ### How do I help?
 
@@ -1121,9 +434,9 @@ You can help by:
 
 - **explicitly switching your server to Traefik** right now (see example configuration in [How do I explicitly switch to Traefik right now?](#how-do-i-explicitly-switch-to-traefik-right-now) above), testing, reporting troubles
 
-- **adding native Traefik support to a role** (requires adding Traefik labels, etc.) - for inspiration, see these roles ([prometheus_node_exporter](https://github.com/mother-of-all-self-hosting/ansible-role-prometheus-node-exporter), [prometheus_postgres_exporter](https://github.com/mother-of-all-self-hosting/ansible-role-prometheus-postgres-exporter)) and how they're hooked into the playbook via [group_vars/matrix_servers](group_vars/matrix_servers).
+- **adding native Traefik support to a role** (requires adding Traefik labels, etc.) - for inspiration, see these roles ([prometheus_node_exporter](https://gitlab.com/etke.cc/roles/prometheus_node_exporter), [prometheus_postgres_exporter](https://gitlab.com/etke.cc/roles/prometheus_postgres_exporter)) and how they're hooked into the playbook via [group_vars/matrix_servers](group_vars/matrix_servers).
 
-- **adding reverse-proxying examples for nginx users** in `examples/nginx`. People who insist on using their own `nginx` server on the same Matrix host, can run Traefik in local-only mode (`traefik_config_entrypoint_web_secure_enabled: false`) and reverse-proxy to the Traefik server
+- **adding reverse-proxying examples for nginx users** in `examples/nginx`. People who insist on using their own `nginx` server on the same Matrix host, can run Traefik in local-only mode (`devture_traefik_config_entrypoint_web_secure_enabled: false`) and reverse-proxy to the Traefik server
 
 
 # 2023-02-10
@@ -1148,7 +461,7 @@ Additional details are available in [Setting up Draupnir](docs/configuring-playb
 
 **TLDR**: the `matrix-prometheus-postgres-exporter` role is now included from another repository. Some variables have been renamed. All functionality remains intact.
 
-The `matrix-prometheus-postgres-exporter` role (which configures [Prometheus Postgres Exporter](https://github.com/prometheus-community/postgres_exporter)) has been extracted from the playbook and now lives in its own repository at https://github.com/mother-of-all-self-hosting/ansible-role-prometheus-postgres-exporter
+The `matrix-prometheus-postgres-exporter` role (which configures [Prometheus Postgres Exporter](https://github.com/prometheus-community/postgres_exporter)) has been extracted from the playbook and now lives in its own repository at https://gitlab.com/etke.cc/roles/prometheus_postgres_exporter
 
 It's still part of the playbook, but is now installed via `ansible-galaxy` (by running `just roles` / `make roles`). Some variables have been renamed (`matrix_prometheus_postgres_exporter_` -> `prometheus_postgres_exporter_`, etc.). The playbook will report all variables that you need to rename to get upgraded. All functionality remains intact.
 
@@ -1166,7 +479,7 @@ Large Coturn deployments (with a huge range of ports specified via `matrix_cotur
 Such deployments don't need to run Coturn within a private container network anymore. Coturn can now run with host-networking by using configuration like this:
 
 ```yaml
-matrix_coturn_container_network: host
+matrix_coturn_docker_network: host
 ```
 
 With such a configuration, **Docker no longer needs to configure thousands of firewall forwarding rules** each time Coturn starts and stops.
@@ -1192,7 +505,7 @@ We've also added `no-multicast-peers` to the default Coturn configuration, but w
 
 **TLDR**: the `matrix-prometheus-node-exporter` role is now included from another repository. Some variables have been renamed. All functionality remains intact.
 
-The `matrix-prometheus-node-exporter` role (which configures [Prometheus node exporter](https://github.com/prometheus/node_exporter)) has been extracted from the playbook and now lives in its own repository at https://github.com/mother-of-all-self-hosting/ansible-role-prometheus-node-exporter
+The `matrix-prometheus-node-exporter` role (which configures [Prometheus node exporter](https://github.com/prometheus/node_exporter)) has been extracted from the playbook and now lives in its own repository at https://gitlab.com/etke.cc/roles/prometheus_node_exporter
 
 It's still part of the playbook, but is now installed via `ansible-galaxy` (by running `just roles` / `make roles`). Some variables have been renamed (`matrix_prometheus_node_exporter_` -> `prometheus_node_exporter_`, etc.). The playbook will report all variables that you need to rename to get upgraded. All functionality remains intact.
 
@@ -1244,20 +557,20 @@ See our [Setting up matrix-bot-chatgpt](docs/configuring-playbook-bot-chatgpt.md
 
 # 2022-11-30
 
-## matrix-postgres-backup has been replaced by the ansible-role-postgres-backup external role
+## matrix-postgres-backup has been replaced by the com.devture.ansible.role.postgres_backup external role
 
-Just like we've [replaced Postgres with an external role](#matrix-postgres-has-been-replaced-by-the-comdevtureansiblerolepostgres-external-role) on 2022-11-28, we're now replacing `matrix-postgres-backup` with an external role - [com.devture.ansible.role.postgres_backup](https://github.com/mother-of-all-self-hosting/ansible-role-postgres_backup).
+Just like we've [replaced Postgres with an external role](#matrix-postgres-has-been-replaced-by-the-comdevtureansiblerolepostgres-external-role) on 2022-11-28, we're now replacing `matrix-postgres-backup` with an external role - [com.devture.ansible.role.postgres_backup](https://github.com/devture/com.devture.ansible.role.postgres_backup).
 
-You'll need to rename your `matrix_postgres_backup`-prefixed variables such that they use a `postgres_backup` prefix.
+You'll need to rename your `matrix_postgres_backup`-prefixed variables such that they use a `devture_postgres_backup` prefix.
 
 
 # 2022-11-28
 
-## matrix-postgres has been replaced by the ansible-role-postgres external role
+## matrix-postgres has been replaced by the com.devture.ansible.role.postgres external role
 
-**TLDR**: the tasks that install the integrated Postgres server now live in an external role - [ansible-role-postgres](https://github.com/mother-of-all-self-hosting/ansible-role-postgres). You'll need to run `make roles` to install it, and to also rename your `matrix_postgres`-prefixed variables to use a `devture_postgres` prefix (e.g. `matrix_postgres_connection_password` -> `postgres_connection_password`). All your data will still be there! Some scripts have moved (`/usr/local/bin/matrix-postgres-cli` -> `/matrix/postgres/bin/cli`).
+**TLDR**: the tasks that install the integrated Postgres server now live in an external role - [com.devture.ansible.role.postgres](https://github.com/devture/com.devture.ansible.role.postgres). You'll need to run `make roles` to install it, and to also rename your `matrix_postgres`-prefixed variables to use a `devture_postgres` prefix (e.g. `matrix_postgres_connection_password` -> `devture_postgres_connection_password`). All your data will still be there! Some scripts have moved (`/usr/local/bin/matrix-postgres-cli` -> `/matrix/postgres/bin/cli`).
 
-The `matrix-postgres` role that has been part of the playbook for a long time has been replaced with the [ansible-role-postgres](https://github.com/mother-of-all-self-hosting/ansible-role-postgres) role. This was done as part of our work to [use external roles for some things](#the-playbook-now-uses-external-roles-for-some-things) for better code re-use and maintainability.
+The `matrix-postgres` role that has been part of the playbook for a long time has been replaced with the [com.devture.ansible.role.postgres](https://github.com/devture/com.devture.ansible.role.postgres) role. This was done as part of our work to [use external roles for some things](#the-playbook-now-uses-external-roles-for-some-things) for better code re-use and maintainability.
 
 The new role is an upgraded version of the old `matrix-postgres` role with these notable differences:
 
@@ -1289,7 +602,7 @@ All scripts installed by the playbook now live in `bin/` directories under `/mat
 **TLDR**: the playbook is 2x faster for running `--tags=setup-all` (and various other tags). It also has new `--tags=install-*` tags (like `--tags=install-all`), which skip uninstallation tasks and bring an additional 2.5x speedup. In total, the playbook can maintain your server 5 times faster.
 
 Our [etke.cc managed Matrix hosting service](https://etke.cc) runs maintenance against hundreds of servers, so the playbook being fast means a lot.
-The [etke.cc Ansible playbook](https://github.com/etkecc/ansible) (which is an extension of this one) is growing to support more and more services (besides just Matrix), so the Matrix playbook being leaner prevents runtimes from becoming too slow and improves the customer experience.
+The [etke.cc Ansible playbook](https://gitlab.com/etke.cc/ansible) (which is an extension of this one) is growing to support more and more services (besides just Matrix), so the Matrix playbook being leaner prevents runtimes from becoming too slow and improves the customer experience.
 
 Even when running `ansible-playbook` manually (as most of us here do), it's beneficial not to waste time and CPU resources.
 
@@ -1507,7 +820,7 @@ You can also control the `background` workers count with `matrix_synapse_workers
 
 ### Appservice worker support is back
 
-We previously had an `appservice` worker type, which [Synapse deprecated in v1.59.0](https://github.com/element-hq/synapse/blob/v1.59.0/docs/upgrade.md#deprecation-of-the-synapseappappservice-and-synapseappuser_dir-worker-application-types). So did we, at the time.
+We previously had an `appservice` worker type, which [Synapse deprecated in v1.59.0](https://github.com/matrix-org/synapse/blob/v1.59.0/docs/upgrade.md#deprecation-of-the-synapseappappservice-and-synapseappuser_dir-worker-application-types). So did we, at the time.
 
 The new way to implement such workers is by using a `generic_worker` and dedicating it to the task of talking to Application Services.
 From now on, we have support for this.
@@ -1517,7 +830,7 @@ You can also control the `appservice` workers count with `matrix_synapse_workers
 
 ### User Directory worker support is back
 
-We previously had a `user_dir` worker type, which [Synapse deprecated in v1.59.0](https://github.com/element-hq/synapse/blob/v1.59.0/docs/upgrade.md#deprecation-of-the-synapseappappservice-and-synapseappuser_dir-worker-application-types). So did we, at the time.
+We previously had a `user_dir` worker type, which [Synapse deprecated in v1.59.0](https://github.com/matrix-org/synapse/blob/v1.59.0/docs/upgrade.md#deprecation-of-the-synapseappappservice-and-synapseappuser_dir-worker-application-types). So did we, at the time.
 
 The new way to implement such workers is by using a `generic_worker` and dedicating it to the task of serving the user directory.
 From now on, we have support for this.
@@ -1558,7 +871,7 @@ See our [Setting up a Cactus Comments server](docs/configuring-playbook-cactus-c
 
 ## Postmoogle email bridge support
 
-Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook can now set up the new [Postmoogle](https://github.com/etkecc/postmoogle) email bridge/bot. Postmoogle is like the [email2matrix bridge](https://github.com/devture/email2matrix) (also [already supported by the playbook](docs/configuring-playbook-email2matrix.md)), but more capable and with the intention to soon support *sending* emails, not just receiving.
+Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook can now set up the new [Postmoogle](https://gitlab.com/etke.cc/postmoogle) email bridge/bot. Postmoogle is like the [email2matrix bridge](https://github.com/devture/email2matrix) (also [already supported by the playbook](docs/configuring-playbook-email2matrix.md)), but more capable and with the intention to soon support *sending* emails, not just receiving.
 
 See our [Setting up Postmoogle email bridging](docs/configuring-playbook-bot-postmoogle.md) documentation to get started.
 
@@ -1713,7 +1026,7 @@ If you're tired of being on an old and problematic Ansible version, you can now
 
 Synapse v1.60 will try to add a new unique index to `state_group_edges` upon startup and could fail if your database is corrupted.
 
-We haven't observed this problem yet, but [the Synapse v1.60.0 upgrade notes](https://github.com/element-hq/synapse/blob/v1.60.0/docs/upgrade.md#adding-a-new-unique-index-to-state_group_edges-could-fail-if-your-database-is-corrupted) mention it, so we're giving you a heads up here in case you're unlucky.
+We haven't observed this problem yet, but [the Synapse v1.60.0 upgrade notes](https://github.com/matrix-org/synapse/blob/v1.60.0/docs/upgrade.md#adding-a-new-unique-index-to-state_group_edges-could-fail-if-your-database-is-corrupted) mention it, so we're giving you a heads up here in case you're unlucky.
 
 **If Synapse fails to start** after your next playbook run, you'll need to:
 
@@ -1746,7 +1059,7 @@ You could then restart services: `ansible-playbook -i inventory/hosts setup.yml
 
 ## buscarron bot support
 
-Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook can now set up [the Buscarron bot](https://github.com/etkecc/buscarron). It's a bot you can use to send any form (HTTP POST, HTML) to a (encrypted) Matrix room
+Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook can now set up [the Buscarron bot](https://gitlab.com/etke.cc/buscarron). It's a bot you can use to send any form (HTTP POST, HTML) to a (encrypted) Matrix room
 
 See our [Setting up Buscarron](docs/configuring-playbook-bot-buscarron.md) documentation to get started.
 
@@ -1771,7 +1084,7 @@ See our [Setting up borg backup](docs/configuring-playbook-backup-borg.md) docum
 
 ## (Compatibility Break) Upgrading to Synapse v1.57 on setups using workers may require manual action
 
-If you're running a worker setup for Synapse (`matrix_synapse_workers_enabled: true`), the [Synapse v1.57 upgrade notes](https://github.com/element-hq/synapse/blob/v1.57.0rc1/docs/upgrade.md#changes-to-database-schema-for-application-services) say that you may need to take special care when upgrading:
+If you're running a worker setup for Synapse (`matrix_synapse_workers_enabled: true`), the [Synapse v1.57 upgrade notes](https://github.com/matrix-org/synapse/blob/v1.57.0rc1/docs/upgrade.md#changes-to-database-schema-for-application-services) say that you may need to take special care when upgrading:
 
 > Synapse v1.57.0 includes a change to the way transaction IDs are managed for application services. If your deployment uses a dedicated worker for application service traffic, **it must be stopped** when the database is upgraded (which normally happens when the main process is upgraded), to ensure the change is made safely without any risk of reusing transaction IDs.
 
@@ -1852,7 +1165,7 @@ See our [Setting up matrix-hookshot](docs/configuring-playbook-bridge-hookshot.m
 
 We believe that 2022 will be the year of the non-Synapse Matrix server!
 
-The playbook was previously quite [Synapse](https://github.com/element-hq/synapse)-centric, but can now accommodate multiple homeserver implementations. Only one homeserver implementation can be active (installed) at a given time.
+The playbook was previously quite [Synapse](https://github.com/matrix-org/synapse)-centric, but can now accommodate multiple homeserver implementations. Only one homeserver implementation can be active (installed) at a given time.
 
 **Synapse is still the default homeserver implementation** installed by the playbook. A new variable (`matrix_homeserver_implementation`) controls which server implementation is enabled (`synapse` or `dendrite` at the given moment).
 
@@ -1887,7 +1200,7 @@ We're excited to gain support for other homeserver implementations, like [Condui
 
 ## Honoroit bot support
 
-Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook can now help you set up [Honoroit](https://github.com/etkecc/honoroit) - a helpdesk bot.
+Thanks to [Aine](https://gitlab.com/etke.cc) of [etke.cc](https://etke.cc/), the playbook can now help you set up [Honoroit](https://gitlab.com/etke.cc/honoroit) - a helpdesk bot.
 
 See our [Setting up Honoroit](docs/configuring-playbook-bot-honoroit.md) documentation to get started.
 
@@ -2423,7 +1736,7 @@ To restore the old behavior of not redirecting anywhere and serving the Synapse
 We used to expose the Synapse Admin APIs publicly (at `https://matrix.DOMAIN/_synapse/admin`).
 These APIs require authentication with a valid access token, so it's not that big a deal to expose them.
 
-However, following [official Synapse's reverse-proxying recommendations](https://github.com/element-hq/synapse/blob/master/docs/reverse_proxy.md#synapse-administration-endpoints), we're no longer exposing `/_synapse/admin` by default.
+However, following [official Synapse's reverse-proxying recommendations](https://github.com/matrix-org/synapse/blob/master/docs/reverse_proxy.md#synapse-administration-endpoints), we're no longer exposing `/_synapse/admin` by default.
 
 If you'd like to restore restore the old behavior and expose `/_synapse/admin` publicly, you can use the following configuration (in your `vars.yml`):
 
@@ -3076,7 +2389,7 @@ To avoid doing it manually, run this:
 
 ## Synapse no longer required
 
-The playbook no longer insists on installing [Synapse](https://github.com/element-hq/synapse) via the `matrix-synapse` role.
+The playbook no longer insists on installing [Synapse](https://github.com/matrix-org/synapse) via the `matrix-synapse` role.
 
 If you would prefer to install Synapse another way and just use the playbook to install other services, it should be possible (`matrix_synapse_enabled: false`).
 
@@ -3478,7 +2791,7 @@ By default, public registration is forbidden.
 
 You can also make people automatically get auto-joined to rooms (controlled via `matrix_synapse_auto_join_rooms`).
 
-## Support for changing the welcome user ID (welcome bot)
+## Support for changing the welcome user id (welcome bot)
 
 By default, `@riot-bot:matrix.org` is used to welcome newly registered users.
 This can be changed to something else (or disabled) via the new `matrix_riot_web_welcome_user_id` variable.
@@ -3608,7 +2921,7 @@ If users participate in large rooms with many other servers, disabling presence
 The playbook now makes the Synapse cache factor configurable, through the playbook's `matrix_synapse_cache_factor` variable (having a default value of `0.5`).
 
 Changing that value allows you to potentially decrease RAM usage or to increase performance by caching more stuff.
-Some information on it is available here: https://github.com/element-hq/synapse#help-synapse-eats-all-my-ram
+Some information on it is available here: https://github.com/matrix-org/synapse#help-synapse-eats-all-my-ram
 
 
 # 2018-09-26

README.md

@@ -13,11 +13,13 @@ We run all services in [Docker](https://www.docker.com/) containers (see [the co
 [Installation](docs/README.md) (upgrades) and some maintenance tasks are automated using [Ansible](https://www.ansible.com/) (see [our Ansible guide](docs/ansible.md)).
 
 
-## Self-hosting or Managed / SaaS
+## Self-hosting or SaaS
 
 This Ansible playbook tries to make self-hosting and maintaining a Matrix server fairly easy. Still, running any service smoothly requires knowledge, time and effort.
 
-If you like the [FOSS](https://en.wikipedia.org/wiki/Free_and_open-source_software) spirit of this Ansible playbook, but prefer to put the responsibility on someone else, you can also [get a managed Matrix server from etke.cc](https://etke.cc?utm_source=github&utm_medium=readme&utm_campaign=mdad) (both hosting and on-premises) - a service built on top of this Ansible playbook but with [additional components](https://etke.cc/help/extras/?utm_source=github&utm_medium=readme&utm_campaign=mdad) and [services](https://etke.cc/services/?utm_source=github&utm_medium=readme&utm_campaign=mdad) which all help you run a Matrix server with ease. Be advised that etke.cc operates on a subscription-based approach and there is no "just set up my server once and be done with it" option.
+If you like the [FOSS](https://en.wikipedia.org/wiki/Free_and_open-source_software) spirit of this Ansible playbook, but prefer to put the responsibility on someone else, you can also [get a managed Matrix server from etke.cc](https://etke.cc?utm_source=github&utm_medium=readme&utm_campaign=mdad) - a service built on top of this Ansible playbook, which can help you run a Matrix server with ease.
+
+If you like learning and experimentation, but would rather reduce future maintenance effort, you can even go for a hybrid approach - self-hosting manually using this Ansible playbook at first and then transferring server maintenance to etke.cc at a later time.
 
 
 ## Supported services
@@ -35,7 +37,7 @@ The homeserver is the backbone of your matrix system. Choose one from the follow
 
 | Name | Default? | Description | Documentation |
 | ---- | -------- | ----------- | ------------- |
-| [Synapse](https://github.com/element-hq/synapse) | ✓ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network | [Link](docs/configuring-playbook-synapse.md) |
+| [Synapse](https://github.com/matrix-org/synapse) | ✓ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network | [Link](docs/configuring-playbook-synapse.md) |
 | [Conduit](https://conduit.rs) | x | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. Conduit is a lightweight open-source server implementation of the Matrix Specification with a focus on easy setup and low system requirements | [Link](docs/configuring-playbook-conduit.md) |
 | [Dendrite](https://github.com/matrix-org/dendrite) | x | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. Dendrite is a second-generation Matrix homeserver written in Go, an alternative to Synapse. | [Link](docs/configuring-playbook-dendrite.md) |
 
@@ -46,7 +48,7 @@ Web clients for matrix that you can host on your own domains.
 | Name | Default? | Description | Documentation |
 | ---- | -------- | ----------- | ------------- |
 | [Element](https://app.element.io/) | ✓ | Web UI, which is configured to connect to your own Synapse server by default | [Link](docs/configuring-playbook-client-element.md) |
-| [Hydrogen](https://github.com/element-hq/hydrogen-web) | x | Lightweight matrix client with legacy and mobile browser support | [Link](docs/configuring-playbook-client-hydrogen.md) |
+| [Hydrogen](https://github.com/vector-im/hydrogen-web) | x | Lightweight matrix client with legacy and mobile browser support | [Link](docs/configuring-playbook-client-hydrogen.md) |
 | [Cinny](https://github.com/ajbura/cinny) |  x | Simple, elegant and secure web client | [Link](docs/configuring-playbook-client-cinny.md) |
 | [SchildiChat](https://schildi.chat/) | x | Based on Element, with a more traditional instant messaging experience | [Link](docs/configuring-playbook-client-schildichat.md) |
 
@@ -61,6 +63,7 @@ Services that run on the server to make the various parts of your installation w
 | [PostgreSQL](https://www.postgresql.org/)| ✓ | Database for Synapse. [Using an external PostgreSQL server](docs/configuring-playbook-external-postgres.md) is also possible. | [Link](docs/configuring-playbook-external-postgres.md) |
 | [Coturn](https://github.com/coturn/coturn) | ✓ | STUN/TURN server for WebRTC audio/video calls | [Link](docs/configuring-playbook-turn.md) |
 | [Traefik](https://doc.traefik.io/traefik/) | ✓ | Web server, listening on ports 80, 443 and 8448 - standing in front of all the other services. Using your own webserver [is possible](docs/configuring-playbook-own-webserver.md) | [Link](docs/configuring-playbook-traefik.md) |
+| [nginx](http://nginx.org/) | x | (Deprecated) Web server, listening on ports 80, 443 and 8448 - standing in front of all the other services. Deprecated in favor of Traefik | [Link](docs/configuring-playbook-nginx.md) |
 | [Let's Encrypt](https://letsencrypt.org/) | ✓ | Free SSL certificate, which secures the connection to all components | [Link](docs/configuring-playbook-ssl-certificates.md) |
 | [ma1sd](https://github.com/ma1uta/ma1sd) | x | Matrix Identity Server | [Link](docs/configuring-playbook-ma1sd.md)
 | [Exim](https://www.exim.org/) | ✓ | Mail server, through which all Matrix services send outgoing email (can be configured to relay through another SMTP server) | [Link](docs/configuring-playbook-email.md) |
@@ -133,16 +136,15 @@ Bots provide various additional functionality to your installation.
 
 | Name | Default? | Description | Documentation |
 | ---- | -------- | ----------- | ------------- |
-| [baibot](https://github.com/etkecc/baibot) | x | A bot that exposes the power of [AI](https://en.wikipedia.org/wiki/Artificial_intelligence) / [Large Language Models](https://en.wikipedia.org/wiki/Large_language_model) to you | [Link](docs/configuring-playbook-bot-baibot.md) |
 | [matrix-reminder-bot](https://github.com/anoadragon453/matrix-reminder-bot) | x | Bot for scheduling one-off & recurring reminders and alarms | [Link](docs/configuring-playbook-bot-matrix-reminder-bot.md) |
 | [matrix-registration-bot](https://github.com/moan0s/matrix-registration-bot) | x | Bot for invitations by creating and managing registration tokens | [Link](docs/configuring-playbook-bot-matrix-registration-bot.md) |
 | [maubot](https://github.com/maubot/maubot) | x | A plugin-based Matrix bot system | [Link](docs/configuring-playbook-bot-maubot.md) |
-| [honoroit](https://github.com/etkecc/honoroit) | x | A helpdesk bot | [Link](docs/configuring-playbook-bot-honoroit.md) |
-| [Postmoogle](https://github.com/etkecc/postmoogle) | x | Email to matrix bot | [Link](docs/configuring-playbook-bot-postmoogle.md) |
+| [honoroit](https://gitlab.com/etke.cc/honoroit) | x | A helpdesk bot | [Link](docs/configuring-playbook-bot-honoroit.md) |
+| [Postmoogle](https://gitlab.com/etke.cc/postmoogle) | x | Email to matrix bot | [Link](docs/configuring-playbook-bot-postmoogle.md) |
 | [Go-NEB](https://github.com/matrix-org/go-neb) | x | A multi functional bot written in Go | [Link](docs/configuring-playbook-bot-go-neb.md) |
 | [Mjolnir](https://github.com/matrix-org/mjolnir) | x | A moderation tool for Matrix | [Link](docs/configuring-playbook-bot-mjolnir.md) |
 | [Draupnir](https://github.com/the-draupnir-project/Draupnir) | x | A moderation tool for Matrix (Fork of Mjolnir) | [Link](docs/configuring-playbook-bot-draupnir.md) |
-| [Buscarron](https://github.com/etkecc/buscarron) | x | Web forms (HTTP POST) to matrix | [Link](docs/configuring-playbook-bot-buscarron.md) |
+| [Buscarron](https://gitlab.com/etke.cc/buscarron) | x | Web forms (HTTP POST) to matrix | [Link](docs/configuring-playbook-bot-buscarron.md) |
 | [matrix-chatgpt-bot](https://github.com/matrixgpt/matrix-chatgpt-bot) | x | ChatGPT from matrix | [Link](docs/configuring-playbook-bot-chatgpt.md) |
 
 ### Administration
@@ -156,7 +158,6 @@ Services that help you in administrating and monitoring your matrix installation
 | Metrics and Graphs | x | Consists of the [Prometheus](https://prometheus.io) time-series database server, the Prometheus [node-exporter](https://prometheus.io/docs/guides/node-exporter/) host metrics exporter, and the [Grafana](https://grafana.com/) web UI | [Link](docs/configuring-playbook-prometheus-grafana.md) |
 | [Borg](https://borgbackup.org) | x | Backups | [Link](docs/configuring-playbook-backup-borg.md) |
 | [Rageshake](https://github.com/matrix-org/rageshake) | x | Bug report server | [Link](docs/configuring-playbook-rageshake.md) |
-| [synapse-usage-exporter](https://github.com/loelkes/synapse-usage-exporter) | x | Export the usage statistics of a Synapse homeserver to be scraped by Prometheus. | [Link](docs/configuring-playbook-synapse-usage-exporter.md) |
 
 ### Misc
 
@@ -165,14 +166,12 @@ Various services that don't fit any other category.
 | Name | Default? | Description | Documentation |
 | ---- | -------- | ----------- | ------------- |
 | [sliding-sync](https://github.com/matrix-org/sliding-sync)| x | Sliding Sync support for clients which require it (e.g. Element X) | [Link](docs/configuring-playbook-sliding-sync-proxy.md) |
-| [synapse_auto_accept_invite](https://github.com/matrix-org/synapse-auto-accept-invite) | x | A Synapse module to automatically accept invites. | [Link](docs/configuring-playbook-synapse-auto-accept-invite.md) |
 | [synapse_auto_compressor](https://github.com/matrix-org/rust-synapse-compress-state/#automated-tool-synapse_auto_compressor) | x | A cli tool that automatically compresses `state_groups` database table in background. | [Link](docs/configuring-playbook-synapse-auto-compressor.md) |
 | [synapse-simple-antispam](https://github.com/t2bot/synapse-simple-antispam) (advanced) | x | A spam checker module | [Link](docs/configuring-playbook-synapse-simple-antispam.md) |
 | [Matrix Corporal](https://github.com/devture/matrix-corporal) (advanced) | x | Reconciliator and gateway for a managed Matrix server | [Link](docs/configuring-playbook-matrix-corporal.md) |
 | [Etherpad](https://etherpad.org) | x | An open source collaborative text editor | [Link](docs/configuring-playbook-etherpad.md) |
 | [Jitsi](https://jitsi.org/) | x | An open source video-conferencing platform | [Link](docs/configuring-playbook-jitsi.md) |
 | [Cactus Comments](https://cactus.chat) | x | A federated comment system built on matrix | [Link](docs/configuring-playbook-cactus-comments.md) |
-| [Pantalaimon](https://github.com/matrix-org/pantalaimon) | x | An E2EE aware proxy daemon | [Link](docs/configuring-playbook-pantalaimon.md) |
 
 
 ## Installation

YEAR-IN-REVIEW.md

@@ -1,106 +0,0 @@
-# 2023
-
-2023 was a year filled with many changes for matrix-docker-ansible-deploy. In this post, we're looking backward at some of the major changes that happened this year, as well as taking a glimpse of what's ahead in 2024.
-
-2023 is probably [the year of AI](https://journal.everypixel.com/2023-the-year-of-ai), with millions of people jumping aboard [OpenAI](https://openai.com/)'s [ChatGPT](https://openai.com/chatgpt) train. matrix-docker-ansible-deploy is no stranger to this and 2023 began with a PR from [bertybuttface](https://github.com/bertybuttface) who added support for [matrix-chatgpt-bot](https://github.com/matrixgpt/matrix-chatgpt-bot) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#chatgpt-support)). While OpenAI's chat GPT website was frequently overloaded in the past, their API was up which made using this bot both convenient and more reliable.
-
-AI aside, with the playbook's focus being containers, we're **doubling down on being "container native"** and becoming more interoperable for people hosting other containers on the Matrix server. In [2022](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/YEAR-IN-REVIEW.md#2022), we've announced a few sibling Ansible playbooks, their use of [Traefik](https://doc.traefik.io/traefik/) and the possiblity of matrix-docker-ansible-deploy also switching to this reverse-proxy. This prediction materialized quickly. The **largest change** in the playbook in 2023 happened way back in February - matrix-docker-ansible-deploy [starting the switch from nginx to Traefik](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#backward-compatibility-reverse-proxy-configuration-changes-and-initial-traefik-support) and then quickly [making Treafik the default reverse-proxy](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#traefik-is-the-default-reverse-proxy-now). As noted in the changelog entries, we envisioned a quick and complete elimination of `matrix-nginx-proxy`, but at the end of 2023, it hasn't happened yet. The playbook is already using Traefik as the front-most reverse-proxy, but nginx (via `matrix-nginx-proxy`) is still around - it has taken a step back and is only used internally for new setups. Work got to a stall due to:
-
-*   complexity: untangling the overly large and messy `matrix-nginx-proxy` component is difficult
-*   the current setup became "good enough" because nginx has become an internal implementation detail for those who have migrated to Traefik. Traefik is already the default public reverse-proxy and gives better possibilities to people wishing to run other web-exposed containers on their Matrix server via [Docker Compose](https://docs.docker.com/compose/), other Ansible playbooks like [mash-playbook](https://github.com/mother-of-all-self-hosting/mash-playbook) (more about this one, below) or any other way.
-
-`matrix-nginx-proxy` is no longer in the way of us being interoperable, but its ugly internal details are still there. It is one more proxy in the long chain of reverse-proxies we have and we'd like to cut it out. This would both make things simpler and also boost performance.
-
-The delay in eliminating `matrix-nginx-proxy` has probably been welcome by many existing users who decided to postpone the Traefik migration a bit longer. In 2024, work on eliminating `matrix-nginx-proxy` will continue with rapid pace. People who are still using `matrix-nginx-proxy` as their front-most reverse-proxy will need to rework their setup. About a year of putting it off has been long enough.
-
-This large Traefik reverse-proxy change was also accompanied by another internal change which began in 2022, but continued in 2023 - **moving non-Matrix-related roles from being internal to the playbook to living their own life outside of it**. Various roles were made more decoupled and moved outside of the playbook, so that other projects (like the [mash-playbook](https://github.com/mother-of-all-self-hosting/mash-playbook) Ansible playbook or other Ansible playbooks) could benefit from them. This led to the **death of a few sibling playbooks** ([gitea-docker-ansible-deploy](https://github.com/spantaleev/gitea-docker-ansible-deploy), [nextcloud-docker-ansible-deploy](https://github.com/spantaleev/nextcloud-docker-ansible-deploy), [peertube-docker-ansible-deploy](https://github.com/spantaleev/peertube-docker-ansible-deploy), [vaultwarden-docker-ansible-deploy](https://github.com/spantaleev/vaultwarden-docker-ansible-deploy)), but brought life to something better, which supports all these services and more.
-
-[mash-playbook](https://github.com/mother-of-all-self-hosting/mash-playbook) is a new Ansible playbook that a few of us (matrix-docker-ansible-deploy contributors) have launched in 2023. It has quickly grown to supports [60+ services](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/supported-services.md) and aims to do the same for [FOSS](https://en.wikipedia.org/wiki/Free_and_open-source_software) service hosting, as matrix-docker-ansible-deploy has done for Matrix - providing a clean and secure way to run a bunch of services in containers on a regular server (that is to say, without Kubernetes, etc.). Thanks to Traefik and Ansible role reuse, it's easy to host both mash-playbook services and matrix-docker-ansible-deploy services on the same server - see mash-playbook's [interoperability](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/interoperability.md) documentation page. If you've been looking for a holiday project or your New Year's Resolutions list contains "self-hosting more services", then you're welcome to give this new playbook a try and join its Matrix room ([#mash-playbook:devture.com](https://matrix.to/#/#mash-playbook:devture.com)).
-
-Because many of the roles are now external to this playbook (defined in the [requirements.yml](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/da27655ef34999fa924bc0a5e641dbd9ba06f133/requirements.yml) file), running `make roles` (or better yet `just roles` via the [just tool](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#support-for-running-commands-via-just)) becomes a necessity each time one pulls playbook updates (`git pull`). Pulling external roles happens via the [ansible-galaxy](https://docs.ansible.com/ansible/latest/cli/ansible-galaxy.html) command-line tool, but if available, the playbook would also use the much faster [agru](https://github.com/etkecc/agru) tool (developed by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/) this year).
-
-With the internal (but important) details out of the way, we can now talk more about **new features that landed in matrix-docker-ansible-deploy in 2023**.
-
-The following **new** **bridges** were added to the playbook in 2023:
-
-*   (2023-01-11) [mautrix-slack](https://mau.dev/mautrix/slack), thanks to a PR by [Cody Neiman](https://github.com/xangelix) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#mautrix-slack-support))
-*   (2023-07-21) [mautrix-gmessages](https://github.com/mautrix/gmessages), thanks to a PR by [Shreyas Ajjarapu](https://github.com/shreyasajj) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#mautrix-gmessages-support))
-*   (2023-08-23) [mautrix-wsproxy](https://github.com/mautrix/wsproxy) for Apple iMessage bridging (when combined with the [mautrix-imessage](https://github.com/mautrix/imessage) bridge running on your Mac or Android phone), thanks to a PR by [Johan Swetzén](https://github.com/jswetzen)
-
-This brings the total number of **[bridges that the playbook supports](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/docs/configuring-playbook.md#bridging-other-networks) up to 30**. There are alternative bridge implementations for various networks and protocols, so the number of "unique bridged networks" is surely much smaller.
-
-A few other **major components and changes** landed in 2023:
-
-*   (2023-02-10) The [Draupnir](https://github.com/the-draupnir-project/Draupnir) moderation tool (successor to [Mjolnir](https://github.com/matrix-org/mjolnir)), thanks to a PR by [FSG-Cat](https://github.com/FSG-Cat) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#draupnir-moderation-tool-bot-support))
-*   (2023-02-10) [Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service) to add Matrix Authentication Support to our Jitsi setup, thanks to a PR by [Jakob S.](https://github.com/jakicoll) from [zakk gGmbH](https://github.com/zakk-it) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#matrix-authentication-support-for-jitsi))
-*   (2023-02-25) The [Rageshake](https://github.com/matrix-org/rageshake) bug report server, thanks to a PR by [Benjamin Kampmann](https://github.com/gnunicorn) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#rageshake-support))
-*   (2023-03-07) [Sliding Sync Proxy](https://github.com/matrix-org/sliding-sync) (currently a necessary component for [Element X](https://element.io/labs/element-x) to work), thanks to: [Benjamin Kampmann](https://github.com/gnunicorn) and [FSG-Cat](https://github.com/FSG-Cat) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#sliding-sync-proxy-element-x-support))
-*   (2023-03-12) synapse-auto-compressor to periodically and automatically run [rust-synapse-compress-state](https://github.com/matrix-org/rust-synapse-compress-state), thanks to a PR by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#synapse-auto-compressor-support))
-*   (2023-07-17) [matrix-media-repo](https://github.com/turt2live/matrix-media-repo),  thanks to a PR by [Michael Hollister](https://github.com/Michael-Hollister) from [FUTO](https://www.futo.org/), the creators of the [Circles app](https://circu.li/) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#matrix-media-repo-support))
-*   (2023-08-31) [SchildiChat](https://github.com/SchildiChat/schildichat-desktop) client app (fork of [element-web)](https://github.com/element-hq/element-web), thanks to a PR by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#schildichat-support))
-*   (2023-10-18) Postgres parameters auto-tuning, thanks to a PR by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#postgres-parameters-are-automatically-tuned-now))
-*   (2023-10-23) Enabling federation of the room directory for Synapse (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#enabling-allow_public_rooms_over_federation-by-default-for-synapse))
-
-The most recent change in the list above (Enabling federation of the room directory for Synapse) has been somewhat **controversial** as it goes against upstream defaults for Synapse. Nevertheless, we believe it **promotes the well-being of the Matrix Federation by improving room discovery**.
-
-**Matrix Federation Stats** (containing the percentage of servers publishing their room directory publicly) are posted to [TWIM](https://matrix.org/category/this-week-in-matrix/) each week by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/). The number of servers which [currently published their room directory publicly](https://matrix.org/blog/2023/12/2/this-week-in-matrix-2023-12-22/#matrix-federation-stats) stands at `26.6%`, which is:
-
-- **2.4% more** than when it was when [first published to TWIM](https://matrix.org/blog/2023/11/03/this-week-in-matrix-2023-11-03/#matrix-federation-stats) (1 month earlier, in November)
-- likely about **15+% more** than from before we flipped the switch (in October)
-
-Hopefully, Synapse defaults would also change the same way and we'd see the number of servers publicly listing their room directory grow faster.
-
-With this configuration change in place, projects like [MatrixRooms.info](https://matrixrooms.info/) (made by [etke.cc](https://etke.cc/)) and potentially others in the future, can discover, index the metadata (room address, title, topic, number of users, etc.) and make public rooms browsable & searchable across the whole Matrix Federation. It'd be great if users joining Matrix could more easily find interesting communities that match their interests!
-
-On the **media side of things**, besides Jitsi getting better Matrix integration (via the aforementioned Matrix User Verification Service), we've also had some [Coturn security tightening](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#backward-compatibility-tightening-coturn-security-can-lead-to-connectivity-issues) as well as [performance optimizations](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#coturn-can-now-use-host-networking) for configurations exposing lots of network ports.
-
-[Element Call](https://github.com/element-hq/element-call) seems to have become a nice and polished product lately (as proclaimed in [The Matrix Holiday Update 2023](https://matrix.org/blog/2023/12/25/the-matrix-holiday-update-2023/)), so 2024 is likely the year we'll see support for it in the playbook. Element Call depends on the [LiveKit](https://livekit.io/) streaming server (which is also useful to developers even by itself), so the first step is likely to see LiveKit support in mash-playbook via a reusable Ansible role. Such a LiveKit Ansible role could later easily land in matrix-docker-ansible-deploy and an Element Call static website could be hooked to it.
-
-Besides these highlights, there were many other relatively large changes announced in our [CHANGELOG](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md) and hundreds of other more minor (but still important) playbook changes that didn't get a mention.
-
-We have **hundreds of contributors to thank for their hard work** on making Matrix self-hosting better for all of us! It should be noted that **support comes in many shapes**, not only in raw code commits and financial help (via [donations](https://liberapay.com/s.pantaleev) or using the [etke.cc managed Matrix hosting service](https://etke.cc/) which is based on matrix-docker-ansible-deploy). It also comes in the shape of code reviews, helping others with [issues](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues), reporting new issues, participating in our support room on Matrix ([#matrix-docker-ansible-deploy:devture.com](https://matrix.to/#/#matrix-docker-ansible-deploy:devture.com)), etc. To everyone who has been there to make matrix-docker-ansible-deploy better in 2023, thank you! 🙇‍♂️
-
-
-# 2022
-
-For [matrix-docker-ansible-deploy](https://github.com/spantaleev/matrix-docker-ansible-deploy/), 2022 started with **breaking the** [**Synapse**](https://github.com/element-hq/synapse) **monopoly** by [adding support](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#dendrite-support) for the [Dendrite](https://github.com/matrix-org/dendrite) Matrix homeserver in early January. This required various internal changes so that the [Ansible](https://www.ansible.com/) playbook would not be Synapse-centric anymore. This groundwork paved the way for continuing in this direction and we [added support](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#conduit-support) for [Conduit](https://conduit.rs/) in August.
-
-When it comes to the `matrix-docker-ansible-deploy` Ansible playbook, 2022 was the year of the non-Synapse homeserver implementation. In practice, none of these homeserver implementations seem ready for prime-time yet and there is no migration path when coming from Synapse. Having done our job of adding support for these alternative homeserver implementations, we can say that we're not getting in the way of future progress. It's time for the Dendrite developers to push harder (development-wise) and for the Synapse developers to take a well-deserved long (infinite) break, and we may get to see more people migrating away from Synapse in the next year(s).
-
-Support for the following new **bridges** was added:
-
-*   [Postmoogle](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#postmoogle-email-bridge-support) for bi-directional email bridging, which supersedes my old and simplistic [email2matrix](https://github.com/devture/email2matrix) one-way bridge-bot
-*   [mautrix-discord](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#mautrix-discord-support)
-*   [go-skype-bridge](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#go-skype-bridge-bridging-support)
-*   [matrix-appservice-kakaotalk](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#matrix-appservice-kakaotalk-support)
-
-Support for the following new **bots** was added:
-
-*   [buscarron bot](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#buscarron-bot-support)
-*   [Honoroit bot](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#honoroit-bot-support)
-*   [matrix-registration-bot](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#matrix-registration-bot-support)
-*   [matrix-hookshot](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#matrix-hookshot-bridging-support)
-*   [maubot](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#maubot-support)
-
-Support for the following new **components and services** was added:
-
-*   [Borg backup](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#borg-backup-support)
-*   [Cactus Comments](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#cactus-comments-support)
-*   [Cinny](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#cinny-support) client support
-*   [ntfy](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#ntfy-push-notifications-support) notifications
-*   [matrix-ldap-registration-proxy](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#matrix-ldap-registration-proxy-support)
-*   [matrix\_encryption\_disabler support](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#matrix_encryption_disabler-support)
-*   [synapse-s3-storage-provider](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#synapse-s3-storage-provider-support) to stop the Synapse media store from being a scalability problem. This brought along [another feature](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#synapse-container-image-customization-support) - an easier way to customize the Synapse container image without having to fork and self-build all of it from scratch
-
-Besides these major user-visible changes, a lot of work also happened **under the hood**:
-
-*   we made [major improvements to Synapse workers](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#potential-backward-compatibility-break-major-improvements-to-synapse-workers) - adding support for stream writers and for running multiple workers of various kinds (federation senders, pushers, background task processing workers, etc.)
-*   we [improved the compatibility of (Synapse + workers) with the rest of the playbook](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#backward-compatibility-break-changing-how-reverse-proxying-to-synapse-works---now-via-a-matrix-synapse-reverse-proxy-companion-service) by introducing a new `matrix-synapse-reverse-proxy-companion-service` service
-*   we started [splitting various Ansible roles out of the Matrix playbook and into independent roles](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#the-playbook-now-uses-external-roles-for-some-things) (e.g. `matrix-postgres` -> [ansible-role-postgres](https://github.com/mother-of-all-self-hosting/ansible-role-postgres)), which could be included in other Ansible playbooks. In fact, these roles already power a few **interesting other sibling playbooks**:
-    *   [gitea-docker-ansible-deploy](https://github.com/spantaleev/gitea-docker-ansible-deploy), for deploying a [Gitea](https://gitea.io/) (self-hosted [Git](https://git-scm.com/) service) server
-    *   [nextcloud-docker-ansible-deploy](https://github.com/spantaleev/nextcloud-docker-ansible-deploy), for deploying a [Nextcloud](https://nextcloud.com/) groupware server
-    *   [vaultwarden-docker-ansible-deploy](https://github.com/spantaleev/vaultwarden-docker-ansible-deploy), for deploying a [Vaultwarden](https://github.com/dani-garcia/vaultwarden) password manager server (unofficial [Bitwarden](https://bitwarden.com/) compatible server)
-
-These sibling playbooks co-exist nicely with one another due to using [Traefik](https://traefik.io/) for reverse-proxying, instead of trying to overtake the whole server by running their own [nginx](https://nginx.org/) reverse-proxy. Hopefully soon, the Matrix playbook will follow suit and be powered by Traefik by default.
-
-Last, but not least, to optimize our [etke.cc managed Matrix hosting service](https://etke.cc/)'s performance (but also individual Ansible playbook runs for people self-hosting by themselves using the playbook), we've [improved playbook runtime 2-5x](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) by employing various Ansible tricks.

bin/rebuild-mautrix-meta-instagram.sh

@@ -1,39 +0,0 @@
-#!/bin/bash
-set -euxo pipefail
-
-# This script rebuilds the mautrix-meta-instagram Ansible role, using the mautrix-meta-messenger role as a source.
-
-if [ $# -eq 0 ]; then
-	echo "Error: No argument supplied. Please provide the path to the roles/custom directory."
-	exit 1
-fi
-
-roles_path=$1
-
-messenger_role_path=$roles_path/matrix-bridge-mautrix-meta-messenger
-instagram_role_path=$roles_path/matrix-bridge-mautrix-meta-instagram
-
-if [ ! -d $messenger_role_path ]; then
-	echo "Cannot find: $messenger_role_path"
-	exit 1
-fi
-
-if [ -d $instagram_role_path ]; then
-	rm -rf $instagram_role_path
-fi
-
-cp -ar $messenger_role_path $instagram_role_path
-
-find "$instagram_role_path" -type f | while read -r file; do
-	sed --in-place 's/matrix_mautrix_meta_messenger_/matrix_mautrix_meta_instagram_/g' "$file"
-	sed --in-place 's/mautrix-meta-messenger/mautrix-meta-instagram/g' "$file"
-done
-
-sed --in-place 's/matrix_mautrix_meta_instagram_meta_mode: \(.*\)/matrix_mautrix_meta_instagram_meta_mode: instagram/g' $instagram_role_path/defaults/main.yml
-sed --in-place 's/matrix_mautrix_meta_instagram_identifier: \(.*\)/matrix_mautrix_meta_instagram_identifier: matrix-mautrix-meta-instagram/g' $instagram_role_path/defaults/main.yml
-
-echo "# matrix-mautrix-meta-instagram" > $instagram_role_path/README.md
-echo "" >> $instagram_role_path/README.md
-echo "This bridge role is derived from the matrix-mautrix-meta-messenger Ansible role via automatic changes (see \`just rebuild-mautrix-meta-instagram\` or \`bin/rebuild-mautrix-meta-instagram.sh\`)." >> $instagram_role_path/README.md
-echo "" >> $instagram_role_path/README.md
-echo "If you'd like to make a change to this role, consider making it to the \`matrix-mautrix-meta-messenger\` role instead." >> $instagram_role_path/README.md

docs/ansible.md

@@ -65,7 +65,7 @@ docker run -it --rm \
 -w /work \
 -v `pwd`:/work \
 --entrypoint=/bin/sh \
-docker.io/devture/ansible:2.17.0-r0-1
+docker.io/devture/ansible:2.14.5-r0-0
 ```
 
 Once you execute the above command, you'll be dropped into a `/work` directory inside a Docker container.
@@ -86,7 +86,7 @@ docker run -it --rm \
 -v `pwd`:/work \
 -v $HOME/.ssh/id_rsa:/root/.ssh/id_rsa:ro \
 --entrypoint=/bin/sh \
-docker.io/devture/ansible:2.17.0-r0-1
+docker.io/devture/ansible:2.14.5-r0-0
 ```
 
 The above command tries to mount an SSH key (`$HOME/.ssh/id_rsa`) into the container (at `/root/.ssh/id_rsa`).

docs/configuring-captcha.md

@@ -1,4 +1,4 @@
-(Adapted from the [upstream project](https://github.com/element-hq/synapse/blob/develop/docs/CAPTCHA_SETUP.md))
+(Adapted from the [upstream project](https://github.com/matrix-org/synapse/blob/develop/docs/CAPTCHA_SETUP.md))
 
 # Overview
 Captcha can be enabled for this home server. This file explains how to do that.
@@ -16,7 +16,7 @@ Must be a reCAPTCHA **v2** key using the "I'm not a robot" Checkbox option
 
 ### Setting ReCaptcha keys
 
-Once registered as above, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Once registered as above, set the following values:
 
 ```yaml
 # for Synapse

docs/configuring-dns.md

@@ -56,7 +56,7 @@ When setting up a SRV record, if you are asked for a service and protocol instea
 
 As the table above illustrates, you need to create 2 subdomains (`matrix.<your-domain>` and `element.<your-domain>`) and point both of them to your new server's IP address (DNS `A` record or `CNAME` record is fine).
 
-The `element.<your-domain>` subdomain may be necessary, because this playbook installs the [Element](https://github.com/element-hq/element-web) web client for you.
+The `element.<your-domain>` subdomain may be necessary, because this playbook installs the [Element](https://github.com/vector-im/element-web) web client for you.
 If you'd rather instruct the playbook not to install Element (`matrix_client_element_enabled: false` when [Configuring the playbook](configuring-playbook.md) later), feel free to skip the `element.<your-domain>` DNS record.
 
 The `dimension.<your-domain>` subdomain may be necessary, because this playbook could install the [Dimension integrations manager](http://dimension.t2bot.io/) for you. Dimension installation is disabled by default, because it's only possible to install it after the other Matrix services are working (see [Setting up Dimension](configuring-playbook-dimension.md) later). If you do not wish to set up Dimension, feel free to skip the `dimension.<your-domain>` DNS record.
@@ -71,15 +71,15 @@ The `sygnal.<your-domain>` subdomain may be necessary, because this playbook cou
 
 The `ntfy.<your-domain>` subdomain may be necessary, because this playbook could install the [ntfy](https://ntfy.sh/) UnifiedPush-compatible push notifications server. The installation of ntfy is disabled by default, it is not a core required component. To learn how to install it, see our [configuring ntfy guide](configuring-playbook-ntfy.md). If you do not wish to set up ntfy, feel free to skip the `ntfy.<your-domain>` DNS record.
 
-The `etherpad.<your-domain>` subdomain may be necessary, because this playbook could install the [Etherpad](https://etherpad.org/) a highly customizable open source online editor providing collaborative editing in really real-time. The installation of Etherpad is disabled by default, it is not a core required component. To learn how to install it, see our [configuring Etherpad guide](configuring-playbook-etherpad.md). If you do not wish to set up Etherpad, feel free to skip the `etherpad.<your-domain>` DNS record.
+The `etherpad.<your-domain>` subdomain may be necessary, because this playbook could install the [Etherpad](https://etherpad.org/) a highly customizable open source online editor providing collaborative editing in really real-time. The installation of etherpad is disabled by default, it is not a core required component. To learn how to install it, see our [configuring etherpad guide](configuring-playbook-etherpad.md). If you do not wish to set up etherpad, feel free to skip the `etherpad.<your-domain>` DNS record.
 
-The `hydrogen.<your-domain>` subdomain may be necessary, because this playbook could install the [Hydrogen](https://github.com/element-hq/hydrogen-web) web client. The installation of Hydrogen is disabled by default, it is not a core required component. To learn how to install it, see our [configuring Hydrogen guide](configuring-playbook-client-hydrogen.md). If you do not wish to set up Hydrogen, feel free to skip the `hydrogen.<your-domain>` DNS record.
+The `hydrogen.<your-domain>` subdomain may be necessary, because this playbook could install the [Hydrogen](https://github.com/vector-im/hydrogen-web) web client. The installation of Hydrogen is disabled by default, it is not a core required component. To learn how to install it, see our [configuring Hydrogen guide](configuring-playbook-client-hydrogen.md). If you do not wish to set up Hydrogen, feel free to skip the `hydrogen.<your-domain>` DNS record.
 
-The `cinny.<your-domain>` subdomain may be necessary, because this playbook could install the [Cinny](https://github.com/ajbura/cinny) web client. The installation of Cinny is disabled by default, it is not a core required component. To learn how to install it, see our [configuring Cinny guide](configuring-playbook-client-cinny.md). If you do not wish to set up Cinny, feel free to skip the `cinny.<your-domain>` DNS record.
+The `cinny.<your-domain>` subdomain may be necessary, because this playbook could install the [Cinny](https://github.com/ajbura/cinny) web client. The installation of cinny is disabled by default, it is not a core required component. To learn how to install it, see our [configuring cinny guide](configuring-playbook-client-cinny.md). If you do not wish to set up cinny, feel free to skip the `cinny.<your-domain>` DNS record.
 
 The `wsproxy.<your-domain>` subdomain may be necessary, because this playbook could install the [wsproxy](https://github.com/mautrix/wsproxy) web client. The installation of wsproxy is disabled by default, it is not a core required component. To learn how to install it, see our [configuring wsproxy guide](configuring-playbook-bridge-mautrix-wsproxy.md). If you do not wish to set up wsproxy, feel free to skip the `wsproxy.<your-domain>` DNS record.
 
-The `buscarron.<your-domain>` subdomain may be necessary, because this playbook could install the [buscarron](https://github.com/etkecc/buscarron) bot. The installation of buscarron is disabled by default, it is not a core required component. To learn how to install it, see our [configuring buscarron guide](configuring-playbook-bot-buscarron.md). If you do not wish to set up buscarron, feel free to skip the `buscarron.<your-domain>` DNS record.
+The `buscarron.<your-domain>` subdomain may be necessary, because this playbook could install the [buscarron](https://gitlab.com/etke.cc/buscarron) bot. The installation of buscarron is disabled by default, it is not a core required component. To learn how to install it, see our [configuring buscarron guide](configuring-playbook-bot-buscarron.md). If you do not wish to set up buscarron, feel free to skip the `buscarron.<your-domain>` DNS record.
 
 ## `_matrix-identity._tcp` SRV record setup
 
@@ -89,7 +89,7 @@ To make the [ma1sd](https://github.com/ma1uta/ma1sd) Identity Server (which this
 
 This is an optional feature for the optionally-installed [ma1sd service](configuring-playbook-ma1sd.md). See [ma1sd's documentation](https://github.com/ma1uta/ma1sd/wiki/mxisd-and-your-privacy#choices-are-never-easy) for information on the privacy implications of setting up this SRV record.
 
-**Note**: This `_matrix-identity._tcp` SRV record for the identity server is different from the `_matrix._tcp` that can be used for Synapse delegation. See [howto-server-delegation.md](howto-server-delegation.md) for more information about delegation.
+Note: This `_matrix-identity._tcp` SRV record for the identity server is different from the `_matrix._tcp` that can be used for Synapse delegation. See [howto-server-delegation.md](howto-server-delegation.md) for more information about delegation.
 
 When you're done with the DNS configuration and ready to proceed, continue with [Getting the playbook](getting-the-playbook.md).
 

docs/configuring-playbook-alertmanager-receiver.md

@@ -1,94 +0,0 @@
-# Setting up matrix-alertmanager-receiver (optional)
-
-The playbook can install and configure the [matrix-alertmanager-receiver](https://github.com/metio/matrix-alertmanager-receiver) service for you. It's a [client](https://prometheus.io/docs/alerting/latest/clients/) for Prometheus' [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), allowing you to deliver alerts to Matrix rooms.
-
-See the project's [documentation](https://github.com/metio/matrix-alertmanager-receiver) to learn more about what this component does and why it might be useful to you.
-
-At the moment, **setting up this service's bot requires some manual actions** as described below in [Account and room preparation](#account-and-room-preparation).
-
-This service is meant to be used with an external [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) instance. It's **not** meant to be integrated with the [Prometheus & Grafana stack](./configuring-playbook-prometheus-grafana.md) installed by this playbook, because the Alertmanager component is not installed by it.
-
-## Adjusting the playbook configuration
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yml
-matrix_alertmanager_receiver_enabled: true
-
-# This exposes matrix-alertmanager-receiver on the `matrix.` domain.
-# Adjust, if necessary.
-matrix_alertmanager_receiver_hostname: "{{ matrix_server_fqn_matrix }}"
-
-# This exposes matrix-alertmanager-receiver under a path prefix containing a random (secret) value.
-# Adjust the `RANDOM_VALUE_HERE` part with a long and secure value.
-matrix_alertmanager_receiver_path_prefix: /matrix-alertmanager-receiver-RANDOM_VALUE_HERE
-
-# If you'd like to change the username for this bot, uncomment and adjust. Otherwise, remove.
-# matrix_alertmanager_receiver_config_matrix_user_id_localpart: "bot.alertmanager.receiver"
-
-# Specify the bot user's access token here.
-# See the "Account and room preparation" section below.
-matrix_alertmanager_receiver_config_matrix_access_token: ''
-
-# Optionally, configure some mappings (URL-friendly room name -> actual Matrix room ID).
-#
-# If you don't configure mappings, you can still deliver alerts using URLs like this:
-# https://matrix.DOMAIN/matrix-alertmanager-receiver-RANDOM_VALUE_HERE/alert/!some-room-id:example.com
-#
-# If a mapping like the one below is configured, you can deliver alerts using friendlier URLs like this:
-# https://matrix.DOMAIN/matrix-alertmanager-receiver-RANDOM_VALUE_HERE/alert/some-room-name
-matrix_alertmanager_receiver_config_matrix_room_mapping:
-  some-room-name: "!some-room-id:{{ matrix_domain }}"
-```
-
-See `roles/custom/matrix-alertmanager-receiver/defaults/main.yml` for additional configuration variables.
-
-
-## Account and room preparation
-
-The playbook can automatically create users, but it cannot automatically obtain access tokens, nor perform any of the other manual actions below.
-
-`matrix-alertmanager-receiver` uses a bot (with a username specified in `matrix_alertmanager_receiver_config_matrix_user_id_localpart` - see above) for delivering messages. You need to **manually register this bot acccount and obtain an access token for it**.
-
-1. [Register a new user](registering-users.md): `ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=bot.alertmanager.receiver password=PASSWORD_FOR_THE_BOT admin=no' --tags=register-user`
-2. [Obtain an access token](obtaining-access-tokens.md) for the bot's user account
-3. Invite the bot to a room where you'd like to alerts to be delivered
-4. Log in as the bot using any Matrix client of your choosing, accept the room invitation from the bot's account and log out
-5. (Optionally) Adjust `matrix_alertmanager_receiver_config_matrix_room_mapping` to create a mapping between the new room and its ID
-
-Steps 1 and 2 above only need to be done once, while preparing your [configuration](#configuration).
-
-Steps 3 and 4 need to be done for each new room you'd like the bot to deliver alerts to. Step 5 is optional and provides cleaner `/alert/` URLs.
-
-
-## Installation
-
-Now that you've [prepared the bot account and room](#account-and-room-preparation) and have [configured the playbook](#configuration), you can run the [installation](installing.md) command: `just install-all`
-
-Then, you can proceed to [Usage](#usage).
-
-
-## Usage
-
-Configure your Prometheus Alertmanager with configuration like this:
-
-```yml
-receivers:
-  - name: matrix
-    webhook_configs:
-      - send_resolved: true
-        url: URL_HERE
-route:
-  group_by:
-    - namespace
-  group_interval: 5m
-  group_wait: 30s
-  receiver: "matrix"
-  repeat_interval: 12h
-  routes:
-    - receiver: matrix
-```
-
-.. where `URL_HERE` looks like `https://matrix.DOMAIN/matrix-alertmanager-receiver-RANDOM_VALUE_HERE/alert/some-room-name` or `https://matrix.DOMAIN/matrix-alertmanager-receiver-RANDOM_VALUE_HERE/alert/!some-room-id:DOMAIN`.
-
-This bot does **not** accept room invitations automatically (like many other bots do). To deliver messages to rooms, **the bot must be joined to all rooms manually** - see Step 5 of the [Account and room preparation](#account-and-room-preparation) section.

docs/configuring-playbook-appservice-double-puppet.md

@@ -1,23 +0,0 @@
-# Setting up Appservice Double Puppet (optional)
-
-Appservice Double Puppet is a homeserver appservice through which bridges (and potentially other services) can impersonate any user on the homeserver.
-
-This is useful for performing [double-puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) via the [appservice method](https://docs.mau.fi/bridges/general/double-puppeting.html#appservice-method-new). The Appservice Double Puppet service is an implementation of this approach.
-
-Previously, bridges supported performing [double-puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) with the help of the [Shared Secret Auth password provider module](./configuring-playbook-shared-secret-auth.md), but this old and hacky solution has been superseded by this Appservice Double Puppet method.
-
-## Adjusting the playbook configuration
-
-To enable the Appservice Double Puppet service, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yml
-matrix_appservice_double_puppet_enabled: true
-```
-
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
-## Usage
-
-When enabled, double puppeting will automatically be enabled for all bridges that support double puppeting via the appservice method.

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

@@ -1,100 +0,0 @@
-# Setting up Draupnir for All/D4A (optional)
-
-The playbook can install and configure the [Draupnir](https://github.com/the-draupnir-project/Draupnir) moderation tool for you in appservice mode.
-
-Appservice mode can be used together with the regular [Draupnir bot](configuring-playbook-bot-draupnir.md) or independently. Details about the differences between the 2 modes are described below.
-
-
-## Draupnir Appservice mode compared to Draupnir bot mode
-
-The administrative functions for managing the appservice are alpha quality and very limited. However, the experience of using an appservice-provisioned Draupnir is on par with the experience of using Draupnir from bot mode except in the case of avatar customisation as described later on in this document.
-
-Draupnir for all is the way to go if you need more than 1 Draupnir instance, but you don't need access to Synapse Admin features as they are not accessible through Draupnir for All (Even though the commands do show up in help).
-
-Draupnir for all in the playbook is rate-limit-exempt automatically as its appservice configuration file does not specify any rate limits.
-
-Normal Draupnir does come with the benefit of access to Synapse Admin features. You are also able to more easily customise your normal Draupnir than D4A as D4A even on the branch with the Avatar command (To be Upstreamed to Mainline Draupnir) that command is clunky as it requires the use of things like Element devtools. In normal draupnir this is a quick operation where you login to Draupnir with a normal client and set Avatar and Display name normally.
-
-Draupnir for all does not support external tooling like [MRU](https://mru.rory.gay) as it can't access Draupnir's user account.
-
-
-## Installation
-
-### 1. 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.
-
-The management room has to be given an alias and be public when you are setting up the bot for the first time as the bot does not differentiate between invites
-and invites to the management room.
-
-This management room is used to control who has access to your D4A deployment. The room stores this data inside of the control room state so your bot must have sufficient powerlevel to send custom state events. This is default 50 or moderator as Element calls this powerlevel.
-
-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 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.
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
-
-You must replace `ALIAS_FROM_STEP_2_GOES_HERE` with the alias you created in step 2.
-
-```yaml
-matrix_appservice_draupnir_for_all_enabled: true
-
-matrix_appservice_draupnir_for_all_master_control_room_alias: "ALIAS_FROM_STEP_2_GOES_HERE"
-```
-
-### 4. Installing
-
-After configuring the playbook, run the [installation](installing.md) command:
-
-```
-ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
-```
-
-
-## Usage
-
-If you made it through all the steps above and your main control room was joined by a user called `@draupnir-main:matrix-homeserver-domain` you have succesfully installed Draupnir for All and can now start using it.
-
-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
-
-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.
-
-The bot requires a powerlevel of 50 in the management room to control who is allowed to use the bot. The bot does currently not say anything if this is true or false. (This is considered a bug and is documented in issue [#297](https://github.com/the-draupnir-project/Draupnir/issues/297))
-
-To allow users or whole homeservers you type /plain @draupnir-main:matrix-homeserver-domain 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.
-
-Open a DM with @draupnir-main:matrix-homeserver-domain and if using Element 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.
-
-Congratulations if you made it all the way here because you now have a fully working Draupnir for all deployment.
-
-### Configuration of D4A
-
-You can refer to the upstream [documentation](https://github.com/the-draupnir-project/Draupnir) for more configuration documentation. Please note that the playbook ships a full copy of the example config that does transfer to provisioned draupnirs in the production-bots.yaml.j2 file in the template directory of the role.
-
-Please note that Config extension does not affect the appservices config as this config is not extensible in current Draupnir anyways. Config extension instead touches the config passed to the Draupnirs that your Appservice creates. So for example below makes all provisioned Draupnirs protect all joined rooms.
-
-You can configure additional options by adding the `matrix_appservice_draupnir_for_all_extension_yaml` variable to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file.
-
-For example to change draupnir's `protectAllJoinedRooms` option to `true` you would add the following to your `vars.yml` file.
-
-```yaml
-matrix_appservice_draupnir_for_all_extension_yaml: |
-  # Your custom YAML configuration goes here.
-  # This configuration extends the default starting configuration (`matrix_appservice_draupnir_for_all_yaml`).
-  #
-  # You can override individual variables from the default configuration, or introduce new ones.
-  #
-  # If you need something more special, you can take full control by
-  # completely redefining `matrix_appservice_draupnir_for_all_yaml`.
-  protectAllJoinedRooms: true
-```

docs/configuring-playbook-backup-borg.md

@@ -64,11 +64,11 @@ To backup without encryption, add `backup_borg_encryption: 'none'` to your vars.
 
 `backup_borg_location_source_directories` defines the list of directories to back up: it's set to `{{ matrix_base_data_path }}` by default, which is the base directory for every service's data, such as Synapse, Postgres and the bridges. You might want to exclude certain directories or file patterns from the backup using the `backup_borg_location_exclude_patterns` variable.
 
-Check the [backup_borg role](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg)'s [defaults/main.yml](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg/-/blob/main/defaults/main.yml) file for the full list of available options.
+Check the [backup_borg role](https://gitlab.com/etke.cc/roles/backup_borg)'s [defaults/main.yml](https://gitlab.com/etke.cc/roles/backup_borg/-/blob/main/defaults/main.yml) file for the full list of available options.
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start

docs/configuring-playbook-base-domain-serving.md

@@ -10,14 +10,14 @@ Usually, there are 2 options:
 
 - either get a separate server for the base domain, just for serving the files necessary for [Server Delegation via a well-known file](howto-server-delegation.md#server-delegation-via-a-well-known-file)
 
-- or, arrange for the Matrix server to serve the base domain. This either involves you [using your own webserver](configuring-playbook-own-webserver.md) or making the integrated webserver serve the base domain for you.
+- or, arrange for the Matrix server to serve the base domain. This either involves you [using your own webserver](configuring-playbook-own-webserver.md) or making the integrated webserver (`matrix-nginx-proxy`) serve the base domain for you.
 
-This documentation page tells you how to do the latter. With some easy changes, we make it possible to serve the base domain from the Matrix server via the integrated webserver.
+This documentation page tells you how to do the latter. With some easy changes, we make it possible to serve the base domain from the Matrix server via the integrated webserver (`matrix-nginx-proxy`).
 
-Just **adjust your DNS records**, so that your base domain is pointed to the Matrix server's IP address (using a DNS `A` record) **and then add the following configuration** to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Just **adjust your DNS records**, so that your base domain is pointed to the Matrix server's IP address (using a DNS `A` record) **and then use the following configuration**:
 
 ```yaml
-matrix_static_files_container_labels_base_domain_enabled: true
+matrix_nginx_proxy_base_domain_serving_enabled: true
 ```
 
 Doing this, the playbook will:
@@ -26,50 +26,27 @@ Doing this, the playbook will:
 
 - serve the `/.well-known/matrix/*` files which are necessary for [Federation Server Discovery](configuring-well-known.md#introduction-to-client-server-discovery) (also see [Server Delegation](howto-server-delegation.md)) and [Client-Server discovery](configuring-well-known.md#introduction-to-client-server-discovery)
 
-- serve a simple homepage at `https://DOMAIN` with content `Hello from DOMAIN` (configurable via the `matrix_static_files_file_index_html_template` variable). You can also [serve a more complicated static website](#serving-a-static-website-at-the-base-domain).
+- serve a simple homepage at `https://DOMAIN` with content `Hello from DOMAIN` (configurable via the `matrix_nginx_proxy_base_domain_homepage_template` variable). You can also [serve a more complicated static website](#serving-a-static-website-at-the-base-domain).
 
 
 ## Serving a static website at the base domain
 
-By default, when "serving the base domain" is enabled, the playbook hosts a simple `index.html` webpage at `/matrix/static-files/public/index.html`.
-The content of this page is taken from the `matrix_static_files_file_index_html_template` variable.
+By default, when "serving the base domain" is enabled, the playbook hosts a simple `index.html` webpage in `/matrix/nginx-proxy/data/matrix-domain`.
+The content of this page is taken from the `matrix_nginx_proxy_base_domain_homepage_template` variable.
 
 If you'd like to host your own static website (more than a single `index.html` page) at the base domain, you can disable the creation of this default `index.html` page like this:
 
 ```yaml
-# Enable base-domain serving
-matrix_static_files_container_labels_base_domain_enabled: true
-
-# Prevent the default index.html file from being installed
-matrix_static_files_file_index_html_enabled: false
-
-# Disable the automatic redirectin of `https://DOMAIN/` to `https://matrix.DOMAIN/`.
-# This gets automatically enabled when you disable `matrix_static_files_file_index_html_enabled`, as we're doing above.
-matrix_static_files_container_labels_base_domain_root_path_redirection_enabled: false
+matrix_nginx_proxy_base_domain_homepage_enabled: false
 ```
 
-With this configuration, Ansible will no longer mess around with the `/matrix/static-files/public/index.html` file.
+With this configuration, Ansible will no longer mess around with the `/matrix/nginx-proxy/data/matrix-domain/index.html` file.
 
-You are then free to upload any static website files to `/matrix/static-files/public` and they will get served at the base domain.
-You can do so manually or by using the [ansible-role-aux](https://github.com/mother-of-all-self-hosting/ansible-role-aux) Ansible role, which is part of this playbook already.
+You are then free to upload any static website files to `/matrix/nginx-proxy/data/matrix-domain` and they will get served at the base domain.
 
 
 ## Serving a more complicated website at the base domain
 
 If you'd like to serve an even more complicated (dynamic) website from the Matrix server, relying on the playbook to serve the base domain is not the best choice.
 
-You have 2 options.
-
-**One way is to host your base domain elsewhere**. This involves:
-- you stopping to serve it from the Matrix server: remove `matrix_static_files_container_labels_base_domain_enabled` from your configuration
-- [configuring Matrix Delegation via well-known](./configuring-well-known.md)
-
-**Another way is to serve the base domain from another (your own) container on the Matrix server**. This involves:
-- telling the playbook to only serve `BASE_DOMAIN/.well-known/matrix` files by adjusting your `vars.yml` configuration like this:
-  - keep `matrix_static_files_container_labels_base_domain_enabled: true`
-  - add an extra: `matrix_static_files_container_labels_base_domain_traefik_path_prefix: /.well-known/matrix`
-- building and running a new container on the Matrix server:
-  - it should be connected to the `traefik` network, so that Traefik can reverse-proxy to it
-  - it should have appropriate [container labels](https://docs.docker.com/config/labels-custom-metadata/), which instruct Traefik to reverse-proxy to it
-
-How you'll be managing building and running this container is up-to-you. You may use of the primitives from [ansible-role-aux](https://github.com/mother-of-all-self-hosting/ansible-role-aux) Ansible role to organize it yourself, or you can set it up in another way.
+Instead, we recommend that you switch to [using your own webserver](configuring-playbook-own-webserver.md) (preferrably nginx). You can then make that webserver host anything you wish, and still easily plug in Matrix services into it.

docs/configuring-playbook-bot-baibot.md

@@ -1,429 +0,0 @@
-# Setting up baibot (optional)
-
-<p align="center">
-	<img src="https://github.com/etkecc/baibot/raw/main/etc/assets/baibot.svg" alt="baibot logo" width="150" />
-	<h1 align="center">baibot</h1>
-</p>
-
-🤖 [baibot](https://github.com/etkecc/baibot) (pronounced bye-bot) is a [Matrix](https://matrix.org/) bot developed by [etke.cc](https://etke.cc/) that exposes the power of [AI](https://en.wikipedia.org/wiki/Artificial_intelligence) / [Large Language Models](https://en.wikipedia.org/wiki/Large_language_model) to you. 🤖
-
-It supports [OpenAI](https://openai.com/)'s [ChatGPT](https://openai.com/blog/chatgpt/) models, as many well as other [☁️ providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md).
-
-It's designed as a more private and [✨ featureful](https://github.com/etkecc/baibot/?tab=readme-ov-file#-features) alternative to [matrix-chatgpt-bot](./configuring-playbook-bot-chatgpt.md). See the [baibot](https://github.com/etkecc/baibot) project and its documentation for more information.
-
-
-## Prerequisites
-
-API access to one or more LLM [☁️ providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md).
-
-
-## Adjusting the playbook configuration
-
-There are **a lot of configuration options** (some required, some possibly required, some optional), so they're **split into multiple sections below**:
-
-<!-- no toc -->
-- [Base configuration](#base-configuration)
-- [👮‍♂️ Administrator configuration](#️-administrator-configuration)
-- [👥 Initial users configuration](#-initial-users-configuration)
-- [🤖 Configuring agents via Ansible](#-configuring-agents-via-ansible)
-- [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers)
-
-Depending on your current `vars.yml` file and desired configuration, **you may require more than just the [base configuration](#base-configuration)**.
-
-
-### Base configuration
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yaml
-matrix_bot_baibot_enabled: true
-
-# Uncomment and adjust this part if you'd like to use a username different than the default
-# matrix_bot_baibot_config_user_mxid_localpart: baibot
-
-# Generate a strong password here. Consider generating it with `pwgen -s 64 1`.
-# If you'd like to change this password subsequently, see the details below.
-matrix_bot_baibot_config_user_password: 'PASSWORD_FOR_THE_BOT'
-
-# An optional passphrase to use for backing up and recovering the bot's encryption keys.
-# You can put any string here, but generating a strong one is preferred (e.g. `pwgen -s 64 1`).
-#
-# If set to null, the recovery module will not be used and losing your session/database
-# will mean you lose access to old messages in encrypted room.
-# It's highly recommended that you configure this to avoid losing access to encrypted messages.
-#
-# Changing this subsequently will also cause you to lose access to old messages in encrypted rooms.
-# For details about changing this subsequently or resetting, see `defaults/main.yml` in the baibot role.
-matrix_bot_baibot_config_user_encryption_recovery_passphrase: 'ANY_LONG_AND_SECURE_PASSPHRASE_STRING_HERE'
-
-# An optional secret for encrypting the bot's session data (see `matrix_bot_baibot_data_path`).
-# This must be 32-bytes (64 characters when HEX-encoded).
-# Generate it with: `openssl rand -hex 32`
-# Set to null or empty to avoid using encryption.
-# Changing this subsequently requires that you also throw away all data (see `matrix_bot_baibot_data_path`)
-matrix_bot_baibot_config_persistence_session_encryption_key: 'A_HEX_STRING_OF_64_CHARACTERS_HERE'
-
-# An optional secret for encrypting bot configuration stored in Matrix's account data.
-# This must be 32-bytes (64 characters when HEX-encoded).
-# Generate it with: `openssl rand -hex 32`
-# Set to null or empty to avoid using encryption.
-# Changing this subsequently will make you lose your configuration.
-matrix_bot_baibot_config_persistence_config_encryption_key: 'A_HEX_STRING_OF_64_CHARACTERS_HERE'
-```
-
-As mentioned above, **this may not be enough**. Continue with the configuration sections below.
-
-
-### 👮‍♂️ Administrator configuration
-
-This is an addition to the [base configuration](#base-configuration).
-
-To specify who is considered a bot [👮‍♂️ Administrator](https://github.com/etkecc/baibot/blob/main/docs/access.md#administrators), you either need to specify `matrix_bot_baibot_config_access_admin_patterns` or `matrix_admin`. The latter is a single variable which affects all bridges and bots.
-
-If `matrix_admin` is already configured in your `vars.yml` configuration, you can skip this section.
-
-**If necessary**, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yml
-# Uncomment to add one or more admins to this bridge:
-#
-# matrix_bot_baibot_config_access_admin_patterns:
-#   - "@*:example.com"
-#   - "@admin:another.com"
-#
-# .. unless you've made yourself an admin of all bots/bridges like this:
-#
-# matrix_admin: '@yourAdminAccount:domain.com'
-```
-
-### 👥 Initial users configuration
-
-By default, **all users on your homeserver are considered allowed users**. If that's OK, you can skip this section.
-
-This is an addition to the [base configuration](#base-configuration).
-
-To specify who is considered a bot [👥 User](https://github.com/etkecc/baibot/blob/main/docs/access.md#user), you may:
-
-- define an **initial** value for `matrix_bot_baibot_config_initial_global_config_user_patterns` Ansible variable, as shown below
-- configure the list at runtime via the bot's `!bai access set-users SPACE_SEPARATED_PATTERNS` command
-
-Configuring `matrix_bot_baibot_config_initial_global_config_user_patterns` is optional, but it can be useful to pre-configure the bot with a list of users who should have access to the bot's features.
-
-**Note**: Once initially configured, the allowed users list **cannot be managed via Ansible anymore**. It can only be managed subsequently via bot commands.
-
-**If necessary**, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yml
-# Uncomment and adjust the bot users if necessary:
-#
-# Subsequent changes to `matrix_bot_baibot_config_initial_global_config_user_patterns` do not affect the bot's behavior.
-# Once initially configured, the allowed users list is managed via bot commands, not via Ansible.
-#
-# matrix_bot_baibot_config_initial_global_config_user_patterns:
-#   - "@*:{{ matrix_bot_baibot_config_homeserver_server_name }}"
-```
-
-### 🤖 Configuring agents via Ansible
-
-You are **not required** to define agents [statically](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md#static-configuration) via Ansible. **To get started quickly**, you can **skip this section and define agents at runtime via chat commands** (following the bot's guidance).
-
-Privileged users (like the [👮‍♂️ Administrator](#️-administrator-configuration), but potentially others too - see the upstream [🔒 access](https://github.com/etkecc/baibot/blob/main/docs/access.md) documentation) can **define agents dynamically at any time** via chat commands.
-
-The Ansible role includes preset variables for easily enabling some [🤖 agents](https://github.com/etkecc/baibot/blob/main/docs/agents.md) on various [☁️ providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md) (e.g. OpenAI, etc).
-
-Besides the presets, the Ansible role also includes support for configuring additional statically-defined agents via the `matrix_bot_baibot_config_agents_static_definitions_custom` Ansible variable.
-
-Agents defined statically and those created dynamically (via chat) are named differently, so **conflict cannot arise**.
-
-Depending on your propensity for [GitOps](https://en.wikipedia.org/wiki/DevOps#GitOps), you may prefer to define agents statically via Ansible, or you may wish to do it dynamically via chat.
-
-Before proceeding, we recommend reading the upstream documentation on [How to choose a provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#how-to-choose-a-provider). In short, it's probably best to go with [OpenAI](#openai).
-
-
-#### Anthropic
-
-You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [Anthropic provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#anthropic) with the help of the playbook's preset variables.
-
-Here's an example **addition** to your `vars.yml` file:
-
-```yml
-matrix_bot_baibot_config_agents_static_definitions_anthropic_enabled: true
-
-matrix_bot_baibot_config_agents_static_definitions_anthropic_config_api_key: "YOUR_API_KEY_HERE"
-
-# If you'd like to use another text-generation agent, uncomment and adjust:
-# matrix_bot_baibot_config_agents_static_definitions_anthropic_config_text_generation_model_id: claude-3-5-sonnet-20240620
-
-# The playbook defines a default prompt for all statically-defined agents.
-# You can adjust it in the `matrix_bot_baibot_config_agents_static_definitions_prompt` variable,
-# or you can adjust it below only for the Anthropic agent.
-# matrix_bot_baibot_config_agents_static_definitions_anthropic_config_text_generation_prompt: "{{ matrix_bot_baibot_config_agents_static_definitions_prompt }}"
-
-# See `defaults/main.yml` in the baibot role for more configuration options.
-```
-
-If you'd like to use more than one model, take a look at the [Configuring additional agents (without a preset)](#configuring-additional-agents-without-a-preset) section below.
-
-💡 You may also wish to use this new agent for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
-
-
-#### Groq
-
-You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [Groq provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#groq) with the help of the playbook's preset variables.
-
-Here's an example **addition** to your `vars.yml` file:
-
-```yml
-matrix_bot_baibot_config_agents_static_definitions_groq_enabled: true
-
-matrix_bot_baibot_config_agents_static_definitions_groq_config_api_key: "YOUR_API_KEY_HERE"
-
-# Specify the text-generation agent you'd like to use
-matrix_bot_baibot_config_agents_static_definitions_groq_config_text_generation_model_id: "llama3-70b-8192"
-
-# The playbook defines a default prompt for all statically-defined agents.
-# You can adjust it in the `matrix_bot_baibot_config_agents_static_definitions_prompt` variable,
-# or you can adjust it below only for the Groq agent.
-# matrix_bot_baibot_config_agents_static_definitions_groq_config_text_generation_prompt: "{{ matrix_bot_baibot_config_agents_static_definitions_prompt }}"
-
-# Uncomment and adjust this part if you're not happy with these speech-to-text defaults:
-#
-# matrix_bot_baibot_config_agents_static_definitions_groq_config_speech_to_text_enabled: true
-# matrix_bot_baibot_config_agents_static_definitions_groq_config_speech_to_text_model_id: whisper-large-v3
-
-# See `defaults/main.yml` in the baibot role for more configuration options.
-```
-
-Because this is a [statically](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md#static-configuration)-defined agent, it will be given a `static/` ID prefix and will be named `static/groq`.
-
-If you'd like to use more than one model, take a look at the [Configuring additional agents (without a preset)](#configuring-additional-agents-without-a-preset) section below.
-
-💡 You may also wish to use this new agent for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
-
-
-#### Mistral
-
-You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [🇫🇷 Mistral provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#mistral) with the help of the playbook's preset variables.
-
-Here's an example **addition** to your `vars.yml` file:
-
-```yml
-matrix_bot_baibot_config_agents_static_definitions_mistral_enabled: true
-
-matrix_bot_baibot_config_agents_static_definitions_mistral_config_api_key: "YOUR_API_KEY_HERE"
-
-# The playbook defines a default prompt for all statically-defined agents.
-# You can adjust it in the `matrix_bot_baibot_config_agents_static_definitions_prompt` variable,
-# or you can adjust it below only for the Mistral agent.
-# matrix_bot_baibot_config_agents_static_definitions_mistral_config_text_generation_prompt: "{{ matrix_bot_baibot_config_agents_static_definitions_prompt }}"
-
-# Uncomment and adjust this part if you're not happy with these defaults:
-# matrix_bot_baibot_config_agents_static_definitions_mistral_config_text_generation_model_id: mistral-large-latest
-
-# See `defaults/main.yml` in the baibot role for more configuration options.
-```
-
-Because this is a [statically](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md#static-configuration)-defined agent, it will be given a `static/` ID prefix and will be named `static/mistral`.
-
-If you'd like to use more than one model, take a look at the [Configuring additional agents (without a preset)](#configuring-additional-agents-without-a-preset) section below.
-
-💡 You may also wish to use this new agent for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
-
-
-#### OpenAI
-
-You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [OpenAI provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#openai) with the help of the playbook's preset variables.
-
-The OpenAI provider is **only meant to be used with OpenAI's official API** and compatibility with other services (which do not fully adhere to the OpenAI API spec completely) is limited. **If you're targeting an OpenAI-compatible service**, use the [OpenAI Compatible](#openai-compatible) provider instead.
-
-Here's an example **addition** to your `vars.yml` file:
-
-```yml
-matrix_bot_baibot_config_agents_static_definitions_openai_enabled: true
-
-matrix_bot_baibot_config_agents_static_definitions_openai_config_api_key: "YOUR_API_KEY_HERE"
-
-# The playbook defines a default prompt for all statically-defined agents.
-# You can adjust it in the `matrix_bot_baibot_config_agents_static_definitions_prompt` variable,
-# or you can adjust it below only for the OpenAI agent.
-# matrix_bot_baibot_config_agents_static_definitions_openai_config_text_generation_prompt: "{{ matrix_bot_baibot_config_agents_static_definitions_prompt }}"
-
-# If you'd like to use another text-generation agent, uncomment and adjust:
-# matrix_bot_baibot_config_agents_static_definitions_openai_config_text_generation_model_id: gpt-4o
-
-# See `defaults/main.yml` in the baibot role for more configuration options.
-```
-
-Because this is a [statically](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md#static-configuration)-defined agent, it will be given a `static/` ID prefix and will be named `static/openai`.
-
-If you'd like to use more than one model, take a look at the [Configuring additional agents (without a preset)](#configuring-additional-agents-without-a-preset) section below.
-
-💡 You may also wish to use this new agent for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
-
-
-#### OpenAI Compatible
-
-You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [OpenAI Compatible provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#openai-compatible) with the help of the playbook's preset variables.
-
-This provider allows you to use OpenAI-compatible API services like [OpenRouter](https://github.com/etkecc/baibot/blob/main/docs/providers.md#openrouter), [Together AI](https://github.com/etkecc/baibot/blob/main/docs/providers.md#together-ai), etc.
-
-Some of these popular services already have **shortcut** providers (see [supported providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md#supported-providers) leading to this one behind the scenes - this make it easier to get started.
-
-As of this moment, the playbook does not include presets for any of these services, so you'll need to [Configuring additional agents (without a preset)](#configuring-additional-agents-without-a-preset).
-
-
-#### Configuring additional agents (without a preset)
-
-The Ansible role may be lacking preset variables for some [☁️ provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md), or you may wish to statically-define an agent on the same provider twice (or more) with different configuration.
-
-It's possible to inject your own agent configuration using the `matrix_bot_baibot_config_agents_static_definitions_custom` Ansible variable.
-
-You can also define providers at runtime, by chatting with the bot, so using Ansible is not a requirement.
-
-Below is an an **example** demonstrating **statically-defining agents via Ansible without using presets**:
-
-```yml
-matrix_bot_baibot_config_agents_static_definitions_custom:
-  # This agent will use the GPT 3.5 model and will only support text-generation,
-  # even though the `openai` provider could support other features (e.g. image-generation).
-  - id: my-openai-gpt-3.5-turbo-agent
-    provider: openai
-    config:
-        base_url: https://api.openai.com/v1
-        api_key: "YOUR_API_KEY_HERE"
-        text_generation:
-          model_id: gpt-3.5-turbo-0125
-          prompt: "{{ matrix_bot_baibot_config_agents_static_definitions_prompt }}"
-          temperature: 1.0
-          max_response_tokens: 4096
-          max_context_tokens: 16385
-        speech_to_text: null
-        text_to_speech: null
-        image_generation: null
-
-  # This agent uses the `openai` provider, but adjusts the base URL, so that it points to some Ollama instance
-  # (which supports an OpenAI-compatible API).
-  - id: my-ollama-agent
-    provider: openai
-    config:
-      base_url: http://ollama-service:1234/v1
-      api_key: ""
-      text_generation:
-        model_id: "llama3.1:8b"
-        prompt: "{{ matrix_bot_baibot_config_agents_static_definitions_prompt }}"
-        temperature: 1.0
-        max_response_tokens: 4096
-        max_context_tokens: 128000
-          speech_to_text: null
-          text_to_speech: null
-          image_generation: null
-```
-
-Because these are [statically](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md#static-configuration)-defined agents, they will be given a `static/` ID prefix and will be named `static/my-openai-gpt-3.5-turbo-agent` and `static/my-ollama-agent`, respectively.
-
-💡 To figure out what to put in the `config` section, refer to the [☁️ provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md) page, which contains **sample configuration YAML for each provider**.
-
-As with any [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md), defining them means they exist. To actually make use of them, they need to be configured as handlers globally or in a specific room - see [Mixing & matching models](https://github.com/etkecc/baibot/blob/main/docs/features.md#mixing--matching-models).
-
-💡 You may also wish to use these new agents for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
-
-
-### 🤝 Configuring initial default handlers
-
-This section is only useful if you're [🤖 Configuring agents via Ansible](#-configuring-agents-via-ansible), as it lets you put these agents to use as soon as the bot starts (by adjusting the bot's **initial global configuration**).
-
-If you're not configuring agents via Ansible, you can skip this section.
-
-This section is only useful the first time around. **Once initially configured the global configuration cannot be managed Ansible**, but only via bot commands.
-
-baibot supports [various purposes](https://github.com/etkecc/baibot/blob/main/docs/features.md):
-
-- [💬 text-generation](https://github.com/etkecc/baibot/blob/main/docs/features.md#-text-generation): communicating with you via text
-
-- [🦻 speech-to-text](https://github.com/etkecc/baibot/blob/main/docs/features.md#-speech-to-text): turning your voice messages into text
-
-- [🗣️ text-to-speech](https://github.com/etkecc/baibot/blob/main/docs/features.md#-text-to-speech): turning bot or users text messages into voice messages
-
-- [🖌️ image-generation](https://github.com/etkecc/baibot/blob/main/docs/features.md#-image-generation): generating images based on instructions
-
-- ❓ catch-all: special purposes, indicating use as a fallback (when no specific handler is configured)
-
-[Mixing & matching models](https://github.com/etkecc/baibot/blob/main/docs/features.md#mixing--matching-models) is made possible by the bot's ability to have different [🤝 handlers](https://github.com/etkecc/baibot/blob/main/docs/configuration/handlers.md) configured for different purposes.
-
-This configuration can be done as a global fallback, or per-room. Both of these [🛠️ configurations](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md) are managed at runtime (viat chat), but **the global configuration can have some initial defaults configured via Ansible**.
-
-You can configure the **initial values** for these via Ansible, via the `matrix_bot_baibot_config_initial_global_config_handler_*` variables.
-
-Example **additional** `vars.yml` configuration:
-
-```yml
-# Note: these are initial defaults for the bot's global configuration.
-# As such, changing any of these values subsequently has no effect on the bot's behavior.
-# Once initially configured, the global configuration is managed via bot commands, not via Ansible.
-
-matrix_bot_baibot_config_initial_global_config_handler_catch_all: static/openai
-
-# In this example, there's no need to define any of these below.
-# Configuring the catch-all purpose handler is enough.
-matrix_bot_baibot_config_initial_global_config_handler_text_generation: null
-matrix_bot_baibot_config_initial_global_config_handler_text_to_speech: null
-matrix_bot_baibot_config_initial_global_config_handler_speech_to_text: null
-matrix_bot_baibot_config_initial_global_config_handler_image_generation: null
-```
-
-**Note**: these are initial defaults for the bot's global configuration. As such, changing any of these values subsequently has no effect on the bot's behavior. **Once initially configured the global configuration cannot be managed Ansible**, but only via bot commands.
-
-
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command:
-
-```sh
-just run-tags install-all,ensure-matrix-users-created,start
-```
-
-**Notes**:
-
-- the `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account
-
-- if you change the bot password (`matrix_bot_baibot_config_user_password` in your `vars.yml` file) subsequently, the bot user's credentials on the homeserver won't be updated automatically. If you'd like to change the bot user's password, use a tool like [synapse-admin](configuring-playbook-synapse-admin.md) to change it, and then update `matrix_bot_baibot_config_user_password` to let the bot know its new password
-
-
-## Usage
-
-To use the bot, invite the `@baibot:DOMAIN` bot user into a room.
-
-If you're an allowed bot [👥 user](https://github.com/etkecc/baibot/blob/main/docs/access.md#user) (see [👥 Initial users configuration](#-initial-users-configuration)), the bot will accept your invitation and join the room.
-
-After joining, the bot will introduce itself and show information about the [✨ features](https://github.com/etkecc/baibot/blob/main/docs/features.md) that are enabled for it.
-
-If you've [🤖 configured one or more agents via Ansible](#-configuring-agents-via-ansible) and have [🤝 configured initial default handlers](#configuring-initial-default-handlers), the bot will immediately be able to make use of these agents for this new room. Otherwise, you will need to configure agents and/or handlers via chat commands.
-
-Send `!bai help` to the room at any time to see the bot's help menu for additional commands.
-
-You can also refer to the upstream [baibot](https://github.com/etkecc/baibot) project's documentation.
-
-
-## Debugging
-
-As with all other services, you can find service logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by running something like `journalctl -fu matrix-bot-baibot`
-
-The default logging level for this service is `info`, but you can increase it to `debug` (or even `trace`) with the following additional configuration:
-
-```yaml
-# Adjust the bot's own logging level.
-matrix_bot_baibot_config_logging_level_baibot: debug
-
-# Adjust the logging level for the mxlink bot library used by the bot.
-matrix_bot_baibot_config_logging_level_mxlink: debug
-
-# Adjust the logging level for other libraries used by the bot.
-# Having this set to a value other than "warn" can be very noisy.
-matrix_bot_baibot_config_logging_level_other_libs: debug
-```
-
-**Alternatively**, you can use a single variable to set the logging level for all of the above (bot + all libraries):
-
-```yaml
-matrix_bot_baibot_config_logging: debug
-```

docs/configuring-playbook-bot-buscarron.md

@@ -1,6 +1,6 @@
 # Setting up Buscarron (optional)
 
-The playbook can install and configure [buscarron](https://github.com/etkecc/buscarron) for you.
+The playbook can install and configure [buscarron](https://gitlab.com/etke.cc/buscarron) for you.
 
 Buscarron is bot that receives HTTP POST submissions of web forms and forwards them to a Matrix room.
 
@@ -20,6 +20,8 @@ matrix_bot_buscarron_hostname: "{{ matrix_server_fqn_matrix }}"
 matrix_bot_buscarron_path_prefix: /buscarron
 ```
 
+**NOTE**: When using `matrix-nginx-proxy` instead of Traefik, you won't be able to override the path prefix. You can only override the domain, but that needs to happen using another variable: `matrix_server_fqn_buscarron` (e.g. `matrix_server_fqn_buscarron: "form.{{ matrix_domain }}"`).
+
 
 ## Adjusting DNS records
 
@@ -56,7 +58,7 @@ matrix_bot_buscarron_spamlist: [] # (optional) list of emails/domains/hosts (wit
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```sh
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,ensure-matrix-users-created,start
@@ -79,7 +81,7 @@ To use the bot, invite the `@bot.buscarron:DOMAIN` to the room you specified in
 </form>
 ```
 
-**Note**: to fight against spam, Buscarron is **very aggressive when it comes to banning** and will ban you if:
+**NOTE**: to fight against spam, Buscarron is **very aggressive when it comes to banning** and will ban you if:
 
 - if you hit the homepage (HTTP `GET` request to `/`)
 - if you submit a form to the wrong URL (`POST` request to `/non-existing-form`)
@@ -87,4 +89,4 @@ To use the bot, invite the `@bot.buscarron:DOMAIN` to the room you specified in
 
 If you get banned, you'd need to restart the process by running the playbook with `--tags=start` or running `systemctl restart matrix-bot-buscarron` on the server.
 
-You can also refer to the upstream [documentation](https://github.com/etkecc/buscarron).
+You can also refer to the upstream [documentation](https://gitlab.com/etke.cc/buscarron).

docs/configuring-playbook-bot-chatgpt.md

@@ -4,8 +4,6 @@ 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!
 
-**Note**: [matrix-chatgpt-bot](https://github.com/matrixgpt/matrix-chatgpt-bot) is now an archived (**unmaintained**) project. Talking to ChatGPT (and many other LLM providers) can happen via the much more featureful [baibot](./configuring-playbook-bot-baibot.md) bot supported by the playbook.
-
 
 ## 1. Register the bot account
 
@@ -57,7 +55,7 @@ You will need to get tokens for ChatGPT.
 
 ## 4. Installing
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```sh
 ansible-playbook -i inventory/hosts setup.yml --tags=install-all,start

docs/configuring-playbook-bot-draupnir.md

@@ -4,9 +4,6 @@ The playbook can install and configure the [draupnir](https://github.com/the-dra
 
 See the project's [documentation](https://github.com/the-draupnir-project/Draupnir) to learn what it does and why it might be useful to you.
 
-This documentation page is about installing Draupnir in bot mode. As an alternative, you can run a multi-instance Draupnir deployment by installing [Draupnir in appservice mode](./configuring-playbook-appservice-draupnir-for-all.md) (called Draupnir-for-all) instead.
-
-
 If your migrating from Mjolnir skip to step 5b.
 
 ## 1. Register the bot account
@@ -35,65 +32,22 @@ Refer to the documentation on [how to obtain an access token](obtaining-access-t
 
 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.
 
-If your Synapse Admin API is exposed to the internet for some reason like running the Synapse Admin Role [Link](/docs/configuring-playbook-synapse-admin.md) or running `matrix_synapse_container_labels_public_client_synapse_admin_api_enabled: true` in your playbook config. If your API is not externally exposed you should still be able to on the local host for your synapse run these commands.
+If your Synapse Admin API is exposed to the internet for some reason like running the Synapse Admin Role [Link](/docs/configuring-playbook-synapse-admin.md) or running `matrix_nginx_proxy_proxy_matrix_client_api_forwarded_location_synapse_admin_api_enabled: true` in your playbook config. If your API is not externally exposed you should still be able to on the local host for your synapse run these commands. 
 
-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.
+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 it self. If you made Draupnir Admin you can just use the Draupnir token.
 
 
 
 ## 4. 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.
+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. The room must be unencrypted since the playbook does not support installing Pantalaimon yet.
 
-If you make the management room encrypted (E2EE), then you MUST enable and use Pantalaimon (see below).
-
-Once you have created the room you need to copy the room ID so you can tell the bot to use that room. In Element you can do this by going to the room's settings, clicking Advanced, and then copying the internal room ID. The room ID will look something like `!QvgVuKq0ha8glOLGMG:DOMAIN`.
+Once you have created the room you need to copy the room ID so you can tell the bot to use that room. In Element you can do this by going to the room's settings, clicking Advanced, and then coping the internal room ID. The room ID will look something like `!QvgVuKq0ha8glOLGMG:DOMAIN`.
 
 Finally invite the `@bot.draupnir:DOMAIN` account you created earlier into the room.
 
 
-## 5. 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
-
-When using Pantalaimon, Draupnir will log in to its bot account itself through Pantalaimon, so configure its username and password.
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
-
-```yaml
-# Enable Pantalaimon. See docs/configuring-playbook-pantalaimon.md
-matrix_pantalaimon_enabled: true
-
-# Enable Draupnir
-matrix_bot_draupnir_enabled: true
-
-# Tell Draupnir to use Pantalaimon
-matrix_bot_draupnir_pantalaimon_use: true
-
-# User name and password for the bot. Required when using Pantalaimon.
-matrix_bot_draupnir_pantalaimon_username: "DRAUPNIR_USERNAME_FROM_STEP_1"
-matrix_bot_draupnir_pantalaimon_password: ### you should create a secure password for the bot account
-
-matrix_bot_draupnir_management_room: "ROOM_ID_FROM_STEP_4_GOES_HERE"
-```
-
-The playbook's `group_vars` will configure other required settings. If using this role separately without the playbook, you also need to configure the two URLs that Draupnir uses to reach the homeserver, one through Pantalaimon and one "raw". This example is taken from the playbook's `group_vars`:
-
-```yaml
-# Endpoint URL that Draupnir uses to interact with the matrix homeserver (client-server API).
-# Set this to the pantalaimon URL if you're using that.
-matrix_bot_draupnir_homeserver_url: "{{ 'http://matrix-pantalaimon:8009' if matrix_bot_draupnir_pantalaimon_use else matrix_addons_homeserver_client_api_url }}"
-
-# Endpoint URL that Draupnir could use to fetch events related to reports (client-server API and /_synapse/),
-# only set this to the public-internet homeserver client API URL, do NOT set this to the pantalaimon URL.
-matrix_bot_draupnir_raw_homeserver_url: "{{ matrix_addons_homeserver_client_api_url }}"
-```
-
-### 5b. 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.
+## 5a. Adjusting the playbook configuration
 
 Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
 
@@ -107,9 +61,9 @@ 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.)
+## 5b. 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.
+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
@@ -123,75 +77,7 @@ ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
 
 ## Usage
 
-You can refer to the upstream [documentation](https://the-draupnir-project.github.io/draupnir-documentation/) for additional ways to use and configure Draupnir and for a more detailed usage guide.
-
-Below is a **non-exhaustive quick-start guide** for the impatient.
-
-### Making Draupnir join and protect a room
-
-Draupnir can be told to self-join public rooms, but it's better to follow this flow which works well for all kinds of rooms:
-
-1. Invite the bot to the room manually ([inviting Draupnir to rooms](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-protected-rooms#inviting-draupnir-to-rooms)). Before joining, the bot *may* ask for confirmation in the Management Room
-
-2. [Give the bot permissions to do its job](#giving-draupnir-permissions-to-do-its-job)
-
-3. Tell it to protect the room (using the [rooms command](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-protected-rooms#using-the-draupnir-rooms-command)) by sending the following command to the Management Room: `!draupnir rooms add !ROOM_ID:DOMAIN`
-
-To have Draupnir provide useful room protection, you need do to a bit more work (at least the first time around).
-You may wish to [Subscribe to a public policy list](#subscribing-to-a-public-policy-list), [Create your own own policy and rules](#creating-your-own-policy-lists-and-rules) and [Enabling built-in protections](#enabling-built-in-protections).
-
-### Giving Draupnir permissions to do its job
-
-For Draupnir to do its job, you need to [give it permissions](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-protected-rooms#giving-draupnir-permissions) in rooms it's protecting. This involves **giving it an Administrator power level**.
-
-**We recommend setting this power level as soon as the bot joins your room** (and before you create new rules), so that it can apply rules as soon as they are available. If the bot is under-privileged, it may fail to apply protections and may not retry for a while (or until your restart it).
-
-### Subscribing to a public policy list
-
-We recommend **subscribing to a public [policy list](https://the-draupnir-project.github.io/draupnir-documentation/concepts/policy-lists)** using the [watch command](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-policy-lists#using-draupnirs-watch-command-to-subscribe-to-policy-rooms).
-
-Polcy lists are maintained in Matrix rooms. A popular policy list is maintained in the public `#community-moderation-effort-bl:neko.dev` room.
-
-You can tell Draupnir to subscribe to it by sending the following command to the Management Room: `!draupnir watch #community-moderation-effort-bl:neko.dev`
-
-#### Creating your own policy lists and rules
-
-We also recommend **creating your own policy lists** with the [list create](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-policy-lists#using-draupnirs-list-create-command-to-create-a-policy-room) command.
-
-You can do so by sending the following command to the Management Room: `!draupnir list create my-bans my-bans-bl`. This will create a policy list having a name (shortcode) of `my-bans` and stored in a public `#my-bans-bl:DOMAIN` room on your server. As soon as you run this command, the bot will invite you to the policy list room.
-
-A policy list does nothing by itself, so the next step is **adding some rules to your policy list**. Policies target a so-called `entity` (one of: `user`, `room` or `server`). These entities are mentioned on the [policy lists](https://the-draupnir-project.github.io/draupnir-documentation/concepts/policy-lists) documentation page and in the Matrix Spec [here](https://spec.matrix.org/v1.11/client-server-api/#mban-recommendation).
-
-The simplest and most useful entity to target is `user`. Below are a few examples using the [ban command](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-users#the-ban-command) and targeting users.
-
-To create rules, you run commands in the Management Room (**not** in the policy list room).
-
-- (ban a single user on a given homeserver): `!draupnir ban @someone:example.com my-bans Rude to others`
-- (ban all users on a given homeserver by using a [wildcard](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-users#wildcards)): `!draupnir ban @*:example.org my-bans Spam server - all users are fake`
-
-As a result of running these commands, you may observe:
-
-- Draupnir creating `m.policy.rule.user` state events in the `#my-bans-bl:DOMAIN` room on your server
-- applying these rules against all rooms that Draupnir is an Administrator in
-
-You can undo bans with the [unban command](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-users#the-unban-command).
-
-### Enabling built-in protections
-
-You can also **turn on various built-in [protections](https://the-draupnir-project.github.io/draupnir-documentation/protections)** like `JoinWaveShortCircuit` ("If X amount of users join in Y time, set the room to invite-only").
-
-To **see which protections are available and which are enabled**, send a `!draupnir protections` command to the Management Room.
-
-To **see the configuration options for a given protection**, send a `!draupnir config get PROTECTION_NAME` (e.g. `!draupnir config get JoinWaveShortCircuit`).
-
-To **set a specific option for a given protection**, send a command like this: `!draupnir config set PROTECTION_NAME.OPTION VALUE` (e.g. `!draupnir config set JoinWaveShortCircuit.timescaleMinutes 30`).
-
-To **enable a given protection**, send a command like this: `!draupnir enable PROTECTION_NAME` (e.g. `!draupnir enable JoinWaveShortCircuit`).
-
-To **disable a given protection**, send a command like this: `!draupnir disable PROTECTION_NAME` (e.g. `!draupnir disable JoinWaveShortCircuit`).
-
-
-## Extending the configuration
+You can refer to the upstream [documentation](https://github.com/the-draupnir-project/Draupnir) for additional ways to use and configure draupnir. Check out their [quickstart guide](https://github.com/the-draupnir-project/Draupnir/blob/main/docs/moderators.md#quick-usage) for some basic commands you can give to the bot.
 
 You can configure additional options by adding the `matrix_bot_draupnir_configuration_extension_yaml` variable to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file.
 
@@ -214,10 +100,7 @@ matrix_bot_draupnir_configuration_extension_yaml: |
 Draupnir supports two methods to receive reports in the management room.
 
 The first method intercepts the report API endpoint of the client-server API, which requires integration with the reverse proxy in front of the homeserver.
-If you are using traefik, this playbook can set this up for you:
-```yaml
-matrix_bot_draupnir_abuse_reporting_enabled: true
-```
+While this playbook uses reverse proxies, it does not yet implement this.
 
 The other method polls an synapse admin API endpoint and is hence only available when using synapse and when the Draupnir user is an admin user (see step 1).
 To enable it, set `pollReports: true` in Draupnir's config:

docs/configuring-playbook-bot-go-neb.md

@@ -39,6 +39,8 @@ matrix_bot_go_neb_hostname: "{{ matrix_server_fqn_matrix }}"
 matrix_bot_go_neb_path_prefix: /go-neb
 ```
 
+**NOTE**: When using `matrix-nginx-proxy` instead of Traefik, you won't be able to override the path prefix. You can only override the domain, but that needs to happen using another variable: `matrix_server_fqn_go_neb` (e.g. `matrix_server_fqn_go_neb: "mybot.{{ matrix_domain }}"`).
+
 
 ## Adjusting DNS records
 
@@ -60,7 +62,7 @@ matrix_bot_go_neb_clients:
   - UserID: "@goneb:{{ matrix_domain }}"
     AccessToken: "MDASDASJDIASDJASDAFGFRGER"
     DeviceID: "DEVICE1"
-    HomeserverURL: "{{ matrix_addons_homeserver_client_api_url }}"
+    HomeserverURL: "{{ matrix_homeserver_container_url }}"
     Sync: true
     AutoJoinRooms: true
     DisplayName: "Go-NEB!"
@@ -69,7 +71,7 @@ matrix_bot_go_neb_clients:
   - UserID: "@another_goneb:{{ matrix_domain }}"
     AccessToken: "MDASDASJDIASDJASDAFGFRGER"
     DeviceID: "DEVICE2"
-    HomeserverURL: "{{ matrix_addons_homeserver_client_api_url }}"
+    HomeserverURL: "{{ matrix_homeserver_container_url }}"
     Sync: false
     AutoJoinRooms: false
     DisplayName: "Go-NEB!"
@@ -176,13 +178,13 @@ matrix_bot_go_neb_services:
       Rooms:
         "!someroom:id":
           Repos:
-            "element-hq/synapse":
+            "matrix-org/synapse":
               Events: ["push", "issues"]
             "matrix-org/dendron":
               Events: ["pull_request"]
         "!anotherroom:id":
           Repos:
-            "element-hq/synapse":
+            "matrix-org/synapse":
               Events: ["push", "issues"]
             "matrix-org/dendron":
               Events: ["pull_request"]

docs/configuring-playbook-bot-honoroit.md

@@ -1,10 +1,10 @@
 # Setting up Honoroit (optional)
 
-The playbook can install and configure [Honoroit](https://github.com/etkecc/honoroit) for you.
+The playbook can install and configure [Honoroit](https://gitlab.com/etke.cc/honoroit) for you.
 
 It's a bot you can use to setup **your own helpdesk on matrix**
 
-See the project's [documentation](https://github.com/etkecc/honoroit#how-it-looks-like) to learn what it does with screenshots and why it might be useful to you.
+See the project's [documentation](https://gitlab.com/etke.cc/honoroit#how-it-looks-like) to learn what it does with screenshots and why it might be useful to you.
 
 
 ## Adjusting the playbook configuration
@@ -14,7 +14,7 @@ Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.
 ```yaml
 matrix_bot_honoroit_enabled: true
 
-# Uncomment and adjust this part if you'd like to use a hostname or path different than the default
+# Uncomment and adjust if you'd like to change the hostname or path
 # matrix_bot_honoroit_hostname: "{{ matrix_server_fqn_matrix }}"
 # matrix_bot_honoroit_path_prefix: /honoroit
 
@@ -31,7 +31,7 @@ matrix_bot_honoroit_roomid: "!yourRoomID:DOMAIN"
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```sh
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,ensure-matrix-users-created,start
@@ -50,4 +50,4 @@ To use the bot, invite the `@honoroit:DOMAIN` to the room you specified in confi
 
 Send `!ho help` to the room to see the bot's help menu for additional commands.
 
-You can also refer to the upstream [documentation](https://github.com/etkecc/honoroit#features).
+You can also refer to the upstream [documentation](https://gitlab.com/etke.cc/honoroit#features).

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

@@ -3,7 +3,8 @@
 The playbook can install and configure [matrix-registration-bot](https://github.com/moan0s/matrix-registration-bot) for you.
 
 The bot allows you to easily **create and manage registration tokens** aka. invitation codes.
-It can be used for an invitation-based server, where you invite someone by sending them a registration token (tokens look like this: `rbalQ0zkaDSRQCOp`). They can register as per normal but have to provide a valid registration token in the final step of the registration process.
+It can be used for an invitation-based server,
+where you invite someone by sending them a registration token (loook like this: `rbalQ0zkaDSRQCOp`). They can register as normal but have to provide a valid registration token in a final step of the registration.
 
 See the project's [documentation](https://github.com/moan0s/matrix-registration-bot#supported-commands) to learn what it
 does and why it might be useful to you.
@@ -16,8 +17,9 @@ To enable the bot, add the following configuration to your `inventory/host_vars/
 ```yaml
 matrix_bot_matrix_registration_bot_enabled: true
 
-# By default, the playbook will set use the bot with a username like this: `@bot.matrix-registration-bot:DOMAIN`.
-# Uncomment and adjust this part if you'd like to use a username different than the default
+#By default, the playbook will set use the bot with a username like 
+## this: `@bot.matrix-registration-bot:DOMAIN`.
+# To use a different username, uncomment & adjust the variable.
 # matrix_bot_matrix_registration_bot_matrix_user_id_localpart: bot.matrix-registration-bot
 
 # Generate a strong password here. Consider generating it with `pwgen -s 64 1`
@@ -30,15 +32,20 @@ matrix_synapse_enable_registration: true
 matrix_synapse_registration_requires_token: true
 ```
 
-The bot account will be created automatically.
+The bot account will be automatically created.
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
+After configuring the playbook, run the [installation](installing.md) command again:
+
+```
+ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
+```
+
 
 ## Usage
 
-To use the bot, start a chat with `@bot.matrix-registration-bot:DOMAIN` (where `DOMAIN` is your base domain, not the `matrix.` domain).
+To use the bot, message `@bot.matrix-registration-bot:DOMAIN` (where `DOMAIN` is your base domain, not the `matrix.` domain).
 
 In this room send `help` and the bot will reply with all options.
 
@@ -46,7 +53,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 methon form access_token to password etc.. you can use
 
 ```bash
 just run-tags bot-matrix-registration-bot-clean-cache

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

@@ -27,7 +27,7 @@ matrix_bot_matrix_reminder_bot_reminders_timezone: Europe/London
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```sh
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,ensure-matrix-users-created,start

docs/configuring-playbook-bot-maubot.md

@@ -14,40 +14,45 @@ Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.
 
 ```yaml
 matrix_bot_maubot_enabled: true
-
-# Uncomment and adjust this part if you'd like to use a username different than the default
-# matrix_bot_maubot_login: bot.maubot
-
-# Generate a strong password here. Consider generating it with `pwgen -s 64 1`
-matrix_bot_maubot_initial_password: PASSWORD_FOR_THE_BOT
-
 matrix_bot_maubot_admins:
   - yourusername: securepassword
 ```
 
-You can add multiple admins. The admin accounts are only used to access the maubot administration interface.
+You can add multiple admins. The admin accounts are not connected to any matrix ID and are only used to access the
+maubot administration interface.
 
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all`
+After configuring the playbook, run the [installation](installing.md) command again:
 
-**Notes**:
-
-- if you change the bot password (`matrix_bot_maubot_initial_password` in your `vars.yml` file) subsequently, the bot user's credentials on the homeserver won't be updated automatically. If you'd like to change the bot user's password, use a tool like [synapse-admin](configuring-playbook-synapse-admin.md) to change it, and then update `matrix_bot_maubot_initial_password` to let the bot know its new password
+```
+ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
+```
 
 ## Usage
 
 You can visit `matrix.<your-domain>/_matrix/maubot/` to manage your available plugins, clients and instances.
 
 You should start in the following order
-1. **Create one or more clients:** A client is a matrix account which the bot will use to message. By default, the playbook creates a `bot.maubot` account (as per the configuration above). You only need to [obtain an access token](#obtaining-an-access-token) for it
+1. **Create one or more clients:** A client is a matrix account which the bot will use to message.
 2. **Upload some Plugins:** Plugins can be obtained from [here](https://github.com/maubot/maubot#plugins) or any other source.
-3. **Create an instance:** An instance is the actual bot. You have to specify a client which the bot instance will use
+3. **Create an instance:** An instance is the actual bot. You have to specify a client which the bot instance will use 
 and the plugin (how the bot will behave)
 
-## Obtaining an access token
+To add a client you first need to create an account and obtain a valid access token.
 
-This can be done via `mbc login` then `mbc auth` (see the [maubot documentation](https://docs.mau.fi/maubot/usage/cli/auth.html)). To run these commands, you'll first need to `exec` into the maubot container with `docker exec -it matrix-bot-maubot sh`.
+## Registering the bot user
 
-Alternatively, you can follow our generic [obtain an access token](obtaining-access-tokens.md) documentation. Be aware that you'd better use the **Obtain an access token via curl** method (not **Obtain an access token via Element**) as the latter will give your bot issues in encrypted rooms. Read [more](https://docs.mau.fi/maubot/usage/basic.html#creating-clients).
+You **need to register the bot user manually** before setting up the bot. You can use the playbook to [register a new user](registering-users.md):
+
+```
+ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=bot.maubot password=PASSWORD_FOR_THE_BOT admin=yes' --tags=register-user
+```
+
+Choose a strong password for the bot. You can generate a good password with a command like this: `pwgen -s 64 1`.
+
+## Obtaining an admin access token
+
+This can be done via `mbc login` then `mbc auth` (see the [maubot documentation](https://docs.mau.fi/maubot/usage/cli/auth.html)). To run these commands you'll need to open the bot docker container with `docker exec -it matrix-bot-maubot sh`
+Alternatively, use Element or curl to [obtain an access token](obtaining-access-tokens.md). However these two methods won't allow the bot to work in encrypted rooms.

docs/configuring-playbook-bot-mjolnir.md

@@ -31,64 +31,21 @@ Refer to the documentation on [how to obtain an access token](obtaining-access-t
 
 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.
 
-If your Synapse Admin API is exposed to the internet for some reason like running the Synapse Admin Role [Link](/docs/configuring-playbook-synapse-admin.md) or running `matrix_synapse_container_labels_public_client_synapse_admin_api_enabled: true` in your playbook config. If your API is not externally exposed you should still be able to on the local host for your synapse run these commands.
+If your Synapse Admin API is exposed to the internet for some reason like running the Synapse Admin Role [Link](/docs/configuring-playbook-synapse-admin.md) or running `matrix_nginx_proxy_proxy_matrix_client_api_forwarded_location_synapse_admin_api_enabled: true` in your playbook config. If your API is not externally exposed you should still be able to on the local host for your synapse run these commands. 
 
-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.
+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 it self. If you made Mjolnir Admin you can just use the Mjolnir token.
 
 ## 4. 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.
+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. The room must be unencrypted since the playbook does not support installing Pantalaimon yet.
 
-If you make the management room encrypted (E2EE), then you MUST enable and use Pantalaimon (see below).
-
-Once you have created the room you need to copy the room ID so you can tell the bot to use that room. In Element you can do this by going to the room's settings, clicking Advanced, and then copying the internal room ID. The room ID will look something like `!QvgVuKq0ha8glOLGMG:DOMAIN`.
+Once you have created the room you need to copy the room ID so you can tell the bot to use that room. In Element you can do this by going to the room's settings, clicking Advanced, and then coping the internal room ID. The room ID will look something like `!QvgVuKq0ha8glOLGMG:DOMAIN`.
 
 Finally invite the `@bot.mjolnir:DOMAIN` account you created earlier into the room.
 
 
 ## 5. 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
-
-When using Pantalaimon, Mjolnir will log in to its bot account itself through Pantalaimon, so configure its username and password.
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
-
-```yaml
-# Enable Pantalaimon. See docs/configuring-playbook-pantalaimon.md
-matrix_pantalaimon_enabled: true
-
-# Enable Mjolnir
-matrix_bot_mjolnir_enabled: true
-
-# Tell Mjolnir to use Pantalaimon
-matrix_bot_mjolnir_pantalaimon_use: true
-
-# User name and password for the bot. Required when using Pantalaimon.
-matrix_bot_mjolnir_pantalaimon_username: "MJOLNIR_USERNAME_FROM_STEP_1"
-matrix_bot_mjolnir_pantalaimon_password: ### you should create a secure password for the bot account
-
-matrix_bot_mjolnir_management_room: "ROOM_ID_FROM_STEP_4_GOES_HERE"
-```
-
-The playbook's `group_vars` will configure other required settings. If using this role separately without the playbook, you also need to configure the two URLs that Mjolnir uses to reach the homeserver, one through Pantalaimon and one "raw". This example is taken from the playbook's `group_vars`:
-
-```yaml
-# Endpoint URL that Mjolnir uses to interact with the matrix homeserver (client-server API).
-# Set this to the pantalaimon URL if you're using that.
-matrix_bot_mjolnir_homeserver_url: "{{ 'http://matrix-pantalaimon:8009' if matrix_bot_mjolnir_pantalaimon_use else matrix_addons_homeserver_client_api_url }}"
-
-# Endpoint URL that Mjolnir could use to fetch events related to reports (client-server API and /_synapse/),
-# only set this to the public-internet homeserver client API URL, do NOT set this to the pantalaimon URL.
-matrix_bot_mjolnir_raw_homeserver_url: "{{ matrix_addons_homeserver_client_api_url }}"
-```
-
-### 5b. 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.
-
 Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
 
 You must replace `ACCESS_TOKEN_FROM_STEP_2_GOES_HERE` and `ROOM_ID_FROM_STEP_4_GOES_HERE` with the your own values.
@@ -101,7 +58,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)
+## 6. Adding mjolnir synapse antispam module (optional)
 
 Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
 
@@ -126,11 +83,11 @@ ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
 
 ## Usage
 
-You can refer to the upstream [documentation](https://github.com/matrix-org/mjolnir) for additional ways to use and configure Mjolnir. Check out their [quickstart guide](https://github.com/matrix-org/mjolnir#quickstart-guide) for some basic commands you can give to the bot.
+You can refer to the upstream [documentation](https://github.com/matrix-org/mjolnir) for additional ways to use and configure mjolnir. Check out their [quickstart guide](https://github.com/matrix-org/mjolnir#quickstart-guide) for some basic commands you can give to the bot.
 
 You can configure additional options by adding the `matrix_bot_mjolnir_configuration_extension_yaml` variable to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file.
 
-For example to change Mjolnir's `recordIgnoredInvites` option to `true` you would add the following to your `vars.yml` file.
+For example to change mjolnir's `recordIgnoredInvites` option to `true` you would add the following to your `vars.yml` file.
 
 ```yaml
 matrix_bot_mjolnir_configuration_extension_yaml: |

docs/configuring-playbook-bot-postmoogle.md

@@ -2,12 +2,12 @@
 
 **Note**: email bridging can also happen via the [email2matrix](configuring-playbook-email2matrix.md) bridge supported by the playbook.
 
-The playbook can install and configure [Postmoogle](https://github.com/etkecc/postmoogle) for you.
+The playbook can install and configure [Postmoogle](https://gitlab.com/etke.cc/postmoogle) for you.
 
-It's a bot/bridge you can use to forward emails to Matrix rooms.
+It's a bot/bridge you can use to forward emails to Matrix rooms. 
 Postmoogle runs an SMTP email server and allows you to assign mailbox addresses to Matrix rooms.
 
-See the project's [documentation](https://github.com/etkecc/postmoogle) to learn what it does and why it might be useful to you.
+See the project's [documentation](https://gitlab.com/etke.cc/postmoogle) to learn what it does and why it might be useful to you.
 
 ## Prerequisites
 
@@ -41,7 +41,7 @@ matrix_bot_postmoogle_password: PASSWORD_FOR_THE_BOT
 # matrix_bot_postmoogle_admins:
 #  - '@yourAdminAccount:domain.com'
 #
-# .. unless you've made yourself an admin of all bots/bridges like this:
+# .. unless you've made yourself an admin of all bridges like this:
 #
 # matrix_admin: '@yourAdminAccount:domain.com'
 ```
@@ -54,7 +54,7 @@ See [Configuring DNS](configuring-dns.md).
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```sh
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,ensure-matrix-users-created,start
@@ -69,19 +69,19 @@ ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,ensure-matrix-use
 
 ## Usage
 
-To use the bot, invite the `@postmoogle:DOMAIN` bot user into a room you want to use as a mailbox.
+To use the bot, invite the `@postmoogle:DOMAIN` into a room you want to use as a mailbox.
 
 Then send `!pm mailbox NAME` to expose this Matrix room as an inbox with the email address `NAME@matrix.domain`. Emails sent to that email address will be forwarded to the room.
 
 Send `!pm help` to the room to see the bot's help menu for additional commands.
 
-You can also refer to the upstream [documentation](https://github.com/etkecc/postmoogle).
+You can also refer to the upstream [documentation](https://gitlab.com/etke.cc/postmoogle).
 
 ### Debug/Logs
 
 As with all other services, you can find their logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by running something like `journalctl -fu matrix-bot-postmoogle`
 
-The default logging level for this bridge is `INFO`, but you can increase it to `DEBUG` with the following additional configuration:
+The default logging level for this bridge is `INFO`, but you can increase it to `DEBUG` with the following additional configuration: 
 
 ```yaml
 matrix_bot_postmoogle_loglevel: 'DEBUG'

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

@@ -28,7 +28,7 @@ matrix_appservice_discord_bot_token: "YOUR DISCORD APP BOT TOKEN"
 matrix_synapse_configuration_extension_yaml: |
   use_appservice_legacy_authorization: true
 ```
-**Note**: This deprecated method is considered insecure.
+*Note*: This deprecated method is considered insecure.
 
 6. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready.
 
@@ -42,14 +42,14 @@ Self-service bridging allows you to bridge specific and existing Matrix rooms to
 matrix_appservice_discord_bridge_enableSelfServiceBridging: true
 ```
 
-**Note**: If self-service bridging is not enabled, `!discord help` commands will return no results.
+_Note: If self-service bridging is not enabled, `!discord help` commands will return no results._
 
 Once self-service is enabled:
 
 1. Start a chat with `@_discord_bot:<YOUR_DOMAIN>` and say `!discord help bridge`.
 2. Follow the instructions in the help output message. If the bot is not already in the Discord server, follow the provided invite link. This may require you to be a administrator of the Discord server.
 
-**Note**: Encrypted Matrix rooms are not supported as of writing.
+_Note: Encrypted Matrix rooms are not supported as of writing._
 
 On the Discord side, you can say `!matrix help` to get a list of available commands to manage the bridge and Matrix users.
 

docs/configuring-playbook-bridge-appservice-irc.md

@@ -6,9 +6,7 @@ The playbook can install and configure the [matrix-appservice-irc](https://githu
 
 See the project's [documentation](https://github.com/matrix-org/matrix-appservice-irc/blob/master/HOWTO.md) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+You'll need to use the following playbook configuration:
 
 ```yaml
 matrix_appservice_irc_enabled: true
@@ -60,10 +58,4 @@ matrix_appservice_irc_ircService_servers:
       lineLimit: 3
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
-## Usage
-
 You then need to start a chat with `@irc_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).

docs/configuring-playbook-bridge-appservice-kakaotalk.md

@@ -2,14 +2,14 @@
 
 The playbook can install and configure [matrix-appservice-kakaotalk](https://src.miscworks.net/fair/matrix-appservice-kakaotalk) for you. `matrix-appservice-kakaotalk` is a bridge to [Kakaotalk](https://www.kakaocorp.com/page/service/service/KakaoTalk?lang=ENG) based on [node-kakao](https://github.com/storycraft/node-kakao) (now unmaintained) and some [mautrix-facebook](https://github.com/mautrix/facebook) code.
 
-**Note**: there have been recent reports (~2022-09-16) that **using this bridge may get your account banned**.
+**NOTE**: there have been recent reports (~2022-09-16) that **using this bridge may get your account banned**.
 
 See the project's [documentation](https://src.miscworks.net/fair/matrix-appservice-kakaotalk) to learn what it does and why it might be useful to you.
 
 
 ## Installing
 
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+To enable the bridge, add this to your `vars.yml` file:
 
 ```yaml
 matrix_appservice_kakaotalk_enabled: true
@@ -17,13 +17,7 @@ matrix_appservice_kakaotalk_enabled: true
 
 You may optionally wish to add some [Additional configuration](#additional-configuration), or to [prepare for double-puppeting](#set-up-double-puppeting) before the initial installation.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command:
-
-```
-ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
-```
+After adjusting your `vars.yml` file, re-run the playbook and restart all services: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`
 
 To make use of the Kakaotalk bridge, see [Usage](#usage) below.
 

docs/configuring-playbook-bridge-appservice-slack.md

@@ -10,42 +10,26 @@ See the project's [documentation](https://github.com/matrix-org/matrix-appservic
 
 loosely based on [this](https://github.com/matrix-org/matrix-appservice-slack#Setup)
 
-1. Create a new Matrix room to act as the administration control room. Note its internal room ID. This can be done in Element by sending a message, opening the options for that message and choosing "view source". The room ID will be displayed near the top.
+1. Create a new Matrix room to act as the administration control room. Note its internal room ID. This can
+be done in Element by making a message, opening the options for that message and choosing "view source". The
+room ID will be displayed near the top.
+2. Enable the bridge with the following configuration in your `vars.yml` file:
 
-2. Enable the bridge by adding the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+```yaml
+matrix_appservice_slack_enabled: true
+matrix_appservice_slack_control_room_id: "Your matrix admin room id"
+```
 
-    ```yaml
-    matrix_appservice_slack_enabled: true
-    matrix_appservice_slack_control_room_id: "Your matrix admin room ID"
-    ```
+3. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready.
+4. Invite the bridge bot user into the admin room:
 
-3. Enable puppeting (optional, but recommended)
-
-    ```yaml
-    matrix_appservice_slack_puppeting_enabled: true
-    matrix_appservice_slack_puppeting_slackapp_client_id: "Your Classic Slack App Client ID"
-    matrix_appservice_slack_puppeting_slackapp_client_secret: "Your Classic Slack App Client Secret"
-    ```
-
-4. Enable Team Sync (optional)
-
-    ```yaml
-    matrix_appservice_slack_team_sync_enabled: true
-    ```
-
-   See https://matrix-appservice-slack.readthedocs.io/en/latest/team_sync/
-
-5. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready.
-
-6. Invite the bridge bot user into the admin room:
-
-    ```
+```
     /invite @slackbot:MY.DOMAIN
-    ```
+```
 
-    Note that the bot's domain is your server's domain **without the `matrix.` prefix.**
+Note that the bot's domain is your server's domain **without the `matrix.` prefix.**
 
-7. Create a Classic Slack App [here](https://api.slack.com/apps?new_classic_app=1).
+5. Create a Classic Slack App [here](https://api.slack.com/apps?new_classic_app=1).
 
     Name the app "matrixbot" (or anything else you'll remember).
 
@@ -53,7 +37,7 @@ loosely based on [this](https://github.com/matrix-org/matrix-appservice-slack#Se
 
     Click on bot users and add a new bot user. We will use this account to bridge the the rooms.
 
-8. Click on Event Subscriptions and enable them and use the request url `https://matrix.DOMAIN/appservice-slack`. Then add the following events and save:
+6. Click on Event Subscriptions and enable them and use the request url `https://matrix.DOMAIN/appservice-slack`. Then add the following events and save:
 
      Bot User Events:
 
@@ -63,7 +47,7 @@ loosely based on [this](https://github.com/matrix-org/matrix-appservice-slack#Se
     - reaction_added
     - reaction_removed
 
-9. Click on OAuth & Permissions and add the following scopes:
+7. Click on OAuth & Permissions and add the following scopes:
 
     - chat:write:bot
     - users:read
@@ -73,62 +57,56 @@ loosely based on [this](https://github.com/matrix-org/matrix-appservice-slack#Se
 
     - files:write:user
 
-    **Note**: In order to make Slack files visible to matrix users, this bridge will make Slack files visible to anyone with the url (including files in private channels). This is different than the current behavior in Slack, which only allows authenticated access to media posted in private channels. See MSC701 for details.
+    Note: In order to make Slack files visible to matrix users, this bridge will make Slack files visible to anyone with the url (including files in private channels). This is different than the current behavior in Slack, which only allows authenticated access to media posted in private channels. See MSC701 for details.
 
-10. Click on Install App and Install App to Workspace. Note the access tokens shown. You will need the Bot User OAuth Access Token and if you want to bridge files, the OAuth Access Token whenever you link a room.
+8. Click on Install App and Install App to Workspace. Note the access tokens shown. You will need the Bot User OAuth Access Token and if you want to bridge files, the OAuth Access Token whenever you link a room.
 
-11. If Team Sync is not enabled, for each channel you would like to bridge, perform the following steps:
+9. For each channel you would like to bridge, perform the following steps:
 
     * Create a Matrix room in the usual manner for your client. Take a note of its Matrix room ID - it will look something like !aBcDeF:example.com.
 
-    * Invite the bot user to both the Slack and Matrix channels you would like to bridge using `/invite @matrixbot` for Slack and `/invite @slackbot:MY.DOMAIN` for Matrix.
+    * Invite the bot user to both the Slack and Matrix channels you would like to bridge using `/invite @matrixbot` for slack and `/invite @slackbot:MY.DOMAIN` for matrix.
 
-    * Determine the "channel ID" that Slack uses to identify the channel. You can see it when you open a given Slack channel in a browser. The URL reads like this: `https://app.slack.com/client/XXX/<the channel ID>/details/`.
+    * Determine the "channel ID" that Slack uses to identify the channel. You can see it when you open a given Slack channel in a browser. The URL reads like this: `https://app.slack.com/client/XXX/<the channel id>/details/`.
 
     * Issue a link command in the administration control room with these collected values as arguments:
 
         with file bridging:
-
-        ```
+    ```
         link --channel_id CHANNELID --room !the-matrix:room.id --slack_bot_token xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx --slack_user_token xoxp-xxxxxxxx-xxxxxxxxx-xxxxxxxx-xxxxxxxx
-        ```
-
+    ```
         without file bridging:
-
-        ```
+    ```
         link --channel_id CHANNELID --room !the-matrix:room.id --slack_bot_token xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx
-        ```
-
+    ```
         These arguments can be shortened to single-letter forms:
-
-        ```
+    ```
         link -I CHANNELID -R !the-matrix:room.id -t xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx
-        ```
+    ```
 
-        Other configuration options are available via the `matrix_appservice_slack_configuration_extension_yaml` variable.
+Other configuration options are available via the `matrix_appservice_slack_configuration_extension_yaml` variable.
 
-12. Unlinking
+10. Unlinking
 
     Channels can be unlinked again like this:
-
     ```
-    unlink --room !the-matrix:room.id
+       unlink --room !the-matrix:room.id
     ```
 
     Unlinking doesn't only disconnect the bridge, but also makes the slackbot leave the bridged matrix room. So in case you want to re-link later, don't forget to re-invite the slackbot into this room again.
 
 ## Troubleshooting
 
-* As always, check the logs: `journalctl -fu matrix-appservice-slack`
+* as always, check the logs:
+`journalctl -fu matrix-appservice-slack`
 
-* Linking: "Room is now pending-name"
-
-  This typically means that you haven't used the correct Slack channel ID. Unlink the room and recheck 'Determine the "channel ID"' from above.
+* linking: "Room is now pending-name"
+This typically means that you haven't used the correct slack channel id. Unlink the room and recheck 'Determine the "channel ID"' from above.
 
 * Messages work from M to S, but not the other way around
+Check you logs, if they say something like
 
-  Check you logs, if they say something like
+`WARN SlackEventHandler Ignoring message from unrecognised slack channel id : %s (%s) <the channel id> <some other id>`
 
-  `WARN SlackEventHandler Ignoring message from unrecognised Slack channel ID : %s (%s) <the channel ID> <some other ID>`
-
-  then unlink your room, reinvite the bot and re-link it again. This may particularly hit you, if you tried to unsuccessfully link your room multiple times without unlinking it after each failed attempt.
+then unlink your room, reinvite the bot and re-link it again. This may particularly hit you, if you tried to unsuccessfully link
+your room multiple times without unlinking it after each failed attempt.

docs/configuring-playbook-bridge-appservice-webhooks.md

@@ -2,7 +2,7 @@
 
 The playbook can install and configure [matrix-appservice-webhooks](https://github.com/turt2live/matrix-appservice-webhooks) for you.
 
-**Note**: This bridge is no longer maintained. While not a 1:1 replacement, the bridge's author suggests taking a look at [matrix-hookshot](https://github.com/Half-Shot/matrix-hookshot) as a replacement, which can also be installed using [this playbook](configuring-playbook-bridge-hookshot.md).
+Note: This bridge is no longer maintained. While not a 1:1 replacement, the bridge's author suggests taking a look at [matrix-hookshot](https://github.com/Half-Shot/matrix-hookshot) as a replacement, which can also be installed using [this playbook](configuring-playbook-bridge-hookshot.md).
 
 This bridge provides support for Slack-compatible webhooks.
 
@@ -20,7 +20,7 @@ matrix_appservice_webhooks_api_secret: '<your_secret>'
 2. In case you want to change the verbosity of logging via `journalctl -fu matrix-appservice-webhooks.service`
 you can adjust this in `inventory/host_vars/matrix.<domain-name>/vars.yml` as well.
 
-**Note**: default value is: `info` and availabe log levels are : `info`, `verbose`
+*Note*: default value is: `info` and availabe log levels are : `info`, `verbose`
 
 ```yaml
 matrix_appservice_webhooks_log_level: '<log_level>'
@@ -31,7 +31,7 @@ matrix_appservice_webhooks_log_level: '<log_level>'
 matrix_synapse_configuration_extension_yaml: |
   use_appservice_legacy_authorization: true
 ```
-**Note**: This deprecated method is considered insecure.
+*Note*: This deprecated method is considered insecure.
 
 4. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready.
 
@@ -39,7 +39,7 @@ matrix_synapse_configuration_extension_yaml: |
 
 6. Invite the bridge bot user to your room:
 
-    - either with `/invite @_webhook:<domain.name>` (**Note**: Make sure you have administration permissions in your room)
+    - either with `/invite @_webhook:<domain.name>` (*Note*: Make sure you have administration permissions in your room)
 
     - or simply add the bridge bot to a private channel (personal channels imply you being an administrator)
 

docs/configuring-playbook-bridge-beeper-linkedin.md

@@ -4,10 +4,6 @@ The playbook can install and configure [beeper-linkedin](https://github.com/beep
 
 See the project's [documentation](https://github.com/beeper/linkedin/blob/master/README.md) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
 ```yaml
 matrix_beeper_linkedin_enabled: true
 ```
@@ -33,17 +29,12 @@ matrix_beeper_linkedin_configuration_extension_yaml: |
 
 You may wish to look at `roles/custom/matrix-bridge-beeper-linkedin/templates/config.yaml.j2` to find other things you would like to configure.
 
-## Installing
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
+## Set up Double Puppeting
 
-## Set up Double Puppeting by enabling Appservice Double Puppet or Shared Secret Auth
+If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have to enable Shared Secred Auth.
 
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service or the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
-
-Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
-
-Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 
 
 ## Usage

docs/configuring-playbook-bridge-go-skype-bridge.md

@@ -5,17 +5,14 @@ The playbook can install and configure
 
 See the project page to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
+To enable the [Skype](https://www.skype.com/) bridge just use the following
+playbook configuration:
 
-To enable the [Skype](https://www.skype.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 matrix_go_skype_bridge_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 

docs/configuring-playbook-bridge-heisenbridge.md

@@ -22,17 +22,11 @@ matrix_heisenbridge_owner: "@you:your-homeserver"
 matrix_heisenbridge_identd_enabled: true
 ```
 
-By default, Heisenbrdige would be exposed on the Matrix domain (`matrix.DOMAIN`, as specified in `matrix_server_fqn_matrix`) under the `/heisenbridge` path prefix. It would handle media requests there (see the [release notes for Heisenbridge v1.15.0](https://github.com/hifi/heisenbridge/releases/tag/v1.15.0)).
-
 That's it! A registration file is automatically generated during the setup phase.
 
 Setting the owner is optional as the first local user to DM `@heisenbridge:your-homeserver` will be made the owner.
 If you are not using a local user you must set it as otherwise you can't DM it at all.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
 ## Usage
 
 After the bridge is successfully running just DM `@heisenbridge:your-homeserver` to start setting it up.

docs/configuring-playbook-bridge-hookshot.md

@@ -6,7 +6,7 @@ Hookshot can bridge [Webhooks](https://en.wikipedia.org/wiki/Webhook) from softw
 
 See the project's [documentation](https://matrix-org.github.io/matrix-hookshot/latest/hookshot.html) to learn what it does in detail and why it might be useful to you.
 
-**Note**: the playbook also supports [matrix-appservice-webhooks](configuring-playbook-bridge-appservice-webhooks.md), which however is soon to be archived by its author and to be replaced by hookshot.
+Note: the playbook also supports [matrix-appservice-webhooks](configuring-playbook-bridge-appservice-webhooks.md), which however is soon to be archived by its author and to be replaced by hookshot.
 
 
 ## Setup Instructions
@@ -27,7 +27,7 @@ Finally, run the playbook (see [installing](installing.md)).
 
 You can enable [experimental encryption](https://matrix-org.github.io/matrix-hookshot/latest/advanced/encryption.html) for Hookshot by adding `matrix_hookshot_experimental_encryption_enabled: true` to your configuration (`vars.yml`) and [executing the playbook](installing.md) again.
 
-Should the crypto store be corrupted, you can reset it by executing this Ansible playbook with the tag `reset-hookshot-encryption` added, for example `ansible-playbook -i inventory/hosts setup.yml -K --tags=reset-hookshot-encryption`.
+Should the crypto store be corrupted, you can reset it by executing this Ansible playbook with the tag `reset-hookshot-encryption` added, for example `ansible-playbook -i inventory/hosts setup.yml -K --tags=reset-hookshot-encryption`).
 
 ## Usage
 
@@ -37,9 +37,9 @@ Make sure the bot is able to send state events (usually the Moderator power leve
 
 Send a `!hookshot help` message to see a list of help commands.
 
-Refer to [Hookshot's documentation](https://matrix-org.github.io/matrix-hookshot/latest/usage.html) for more details about using the bridge's various features.
+Refer to [Hookshot's documentation](https://matrix-org.github.io/matrix-hookshot/latest/usage.html) for more details about using the brige's various features.
 
-**Important**: Note that the different listeners are bound to certain paths which might differ from those assumed by the hookshot documentation, see [URLs for bridges setup](#urls-for-bridges-setup) below.
+**Important:** Note that the different listeners are bound to certain paths which might differ from those assumed by the hookshot documentation, see [URLs for bridges setup](#urls-for-bridges-setup) below.
 
 
 ## More setup documentation
@@ -50,17 +50,16 @@ Unless indicated otherwise, the following endpoints are reachable on your `matri
 
 | listener | default path | variable | used as |
 |---|---|---|---|
-| - | `/hookshot/webhooks/` | `matrix_hookshot_webhook_endpoint` | Webhook-prefix, which affects all webhook-related URLs below |
-| generic | `/hookshot/webhooks/webhook` | `matrix_hookshot_generic_endpoint` | Generic webhooks |
+| webhooks | `/hookshot/webhooks/` | `matrix_hookshot_webhook_endpoint` | generics, GitHub "Webhook URL", GitLab "URL", etc. |
 | github oauth | `/hookshot/webhooks/oauth` | `matrix_hookshot_github_oauth_endpoint` | GitHub "Callback URL" |
 | jira oauth | `/hookshot/webhooks/jira/oauth` | `matrix_hookshot_jira_oauth_endpoint` | JIRA OAuth |
 | figma endpoint | `/hookshot/webhooks/figma/webhook` | `matrix_hookshot_figma_endpoint` | Figma |
 | provisioning | `/hookshot/v1/` | `matrix_hookshot_provisioning_endpoint` | Dimension [provisioning](#provisioning-api) |
 | appservice | `/hookshot/_matrix/app/` | `matrix_hookshot_appservice_endpoint` | Matrix server |
 | widgets | `/hookshot/widgetapi/` | `matrix_hookshot_widgets_endpoint` | Widgets |
-| metrics | `/metrics/hookshot` | `matrix_hookshot_metrics_enabled` and exposure enabled via `matrix_hookshot_metrics_proxying_enabled` or `matrix_metrics_exposure_enabled`. Read more in the [Metrics section](#metrics) below. | Prometheus |
+| metrics | `/metrics/hookshot` | `matrix_hookshot_metrics_enabled` and `matrix_hookshot_metrics_proxying_enabled`. Requires `/metrics/*` endpoints to also be enabled via `matrix_nginx_proxy_proxy_matrix_metrics_enabled` (see the `matrix-nginx-proxy` role). Read more in the [Metrics section](#metrics) below. | Prometheus |
 
-Also see the various `matrix_hookshot_container_labels_*` variables in [default/main.yml](/roles/custom/matrix-bridge-hookshot/default/main.yml), which expose URLs publicly.
+See also `matrix_hookshot_matrix_nginx_proxy_configuration` in [init.yml](/roles/custom/matrix-bridge-hookshot/tasks/inject_into_nginx_proxy.yml).
 
 The different listeners are also reachable *internally* in the docker-network via the container's name (configured by `matrix_hookshot_container_url`) and on different ports (e.g. `matrix_hookshot_appservice_port`). Read [main.yml](/roles/custom/matrix-bridge-hookshot/defaults/main.yml) in detail for more info.
 
@@ -92,12 +91,10 @@ Metrics are **only enabled by default** if the builtin [Prometheus](configuring-
 
 To explicitly enable metrics, use `matrix_hookshot_metrics_enabled: true`. This only exposes metrics over the container network, however.
 
-**To collect metrics from an external Prometheus server**, besides enabling metrics as described above, you will also need to enable metrics exposure on `https://matrix.DOMAIN/metrics/hookshot` by:
+**To collect metrics from an external Prometheus server**, besides enabling metrics as described above, you will also need to:
 
-- either enabling metrics exposure for Hookshot via `matrix_hookshot_metrics_proxying_enabled: true`
-- or enabling metrics exposure for all services via `matrix_metrics_exposure_enabled: true`
-
-Whichever one you go with, by default metrics are exposed publicly **without** password-protection. See [the Prometheus and Grafana docs](configuring-playbook-prometheus-grafana.md) for details about password-protection for metrics.
+- enable the `https://matrix.DOMAIN/metrics/*` endpoints on `matrix.DOMAIN` using `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true` (see the `matrix-nginx-role` or [the Prometheus and Grafana docs](configuring-playbook-prometheus-grafana.md) for enabling this feature)
+- expose the Hookshot metrics under `https://matrix.DOMAIN/metrics/hookshot` by setting `matrix_hookshot_metrics_proxying_enabled: true`
 
 ### Collision with matrix-appservice-webhooks
 

docs/configuring-playbook-bridge-matrix-bridge-sms.md

@@ -6,15 +6,15 @@ See the project page to learn what it does and why it might be useful to you.
 
 **The bridge uses [android-sms-gateway-server](https://github.com/RebekkaMa/android-sms-gateway-server). You need to configure it first.**
 
-## Adjusting the playbook configuration
+To enable the bridge just use the following
+playbook configuration:
 
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 matrix_sms_bridge_enabled: true
 
-# (optional but recommended) a room ID to a default room
-matrix_sms_bridge_default_room: ""
+# (optional but recommended) a room id to a default room
+matrix_sms_bridge_default_room: "" 
 
 # (optional but recommended) configure your server location
 matrix_sms_bridge_default_region: DE
@@ -31,9 +31,6 @@ matrix_sms_bridge_provider_android_truststore_password: 123
 
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 

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

@@ -15,9 +15,9 @@ There are 2 ways to login to discord using this bridge, either by [scanning a QR
 
 If this is a dealbreaker for you, consider using one of the other Discord bridges supported by the playbook: [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) or [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md). These come with their own complexity and limitations, however, so we recommend that you proceed with this one if possible.
 
-## Adjusting the playbook configuration
+## Installing
 
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+To enable the bridge, add this to your `vars.yml` file:
 
 ```yaml
 matrix_mautrix_discord_enabled: true
@@ -25,13 +25,7 @@ matrix_mautrix_discord_enabled: true
 
 You may optionally wish to add some [Additional configuration](#additional-configuration), or to [prepare for double-puppeting](#set-up-double-puppeting) before the initial installation.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command:
-
-```
-ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
-```
+After adjusting your `vars.yml` file, re-run the playbook and restart all services: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`
 
 To make use of the bridge, see [Usage](#usage) below.
 
@@ -50,13 +44,11 @@ Take a look at:
 
 If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
 
-#### Method 1: automatically, by enabling Appservice Double Puppet or Shared Secret Auth
+#### Method 1: automatically, by enabling Shared Secret Auth
 
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service or the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 
-Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
-
-Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
+This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
 
 #### Method 2: manually, by asking each user to provide a working access token
 

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

@@ -1,15 +1,9 @@
 # Setting up Mautrix Facebook (optional)
 
-**Note**: bridging to Facebook [Messenger](https://messenger.com) via this bridge is being [superseded by a new bridge - mautrix-meta](https://github.com/mautrix/facebook/issues/332). For now, the mautrix-facebook bridge continues to work, but the new [mautrix-meta-messenger bridge](./configuring-playbook-bridge-mautrix-meta-messenger.md) is better and more supported. Consider using that bridge instead of this one.
-
 The playbook can install and configure [mautrix-facebook](https://github.com/mautrix/facebook) for you.
 
 See the project's [documentation](https://github.com/mautrix/facebook/blob/master/ROADMAP.md) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
 ```yaml
 matrix_mautrix_facebook_enabled: true
 ```
@@ -47,9 +41,6 @@ matrix_mautrix_facebook_configuration_extension_yaml: |
 
 You may wish to look at `roles/custom/matrix-bridge-mautrix-facebook/templates/config.yaml.j2` and `roles/custom/matrix-bridge-mautrix-facebook/defaults/main.yml` to find other things you would like to configure.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Set up Double Puppeting
 

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

@@ -4,27 +4,21 @@ The playbook can install and configure [mautrix-gmessages](https://github.com/ma
 
 See the project's [documentation](https://docs.mau.fi/bridges/go/gmessages/index.html) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Use the following playbook configuration:
 
 ```yaml
 matrix_mautrix_gmessages_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
 ## Set up Double Puppeting
 
 If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
 
-### Method 1: automatically, by enabling Appservice Double Puppet
+### Method 1: automatically, by enabling Shared Secret Auth
 
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service for this playbook.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 
-Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
+This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
 
 ### Method 2: manually, by asking each user to provide a working access token
 

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

@@ -4,29 +4,23 @@ The playbook can install and configure [mautrix-googlechat](https://github.com/m
 
 See the project's [documentation](https://docs.mau.fi/bridges/python/googlechat/index.html) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
+To enable the [Google Chat](https://chat.google.com/) bridge just use the following playbook configuration:
 
-To enable the [Google Chat](https://chat.google.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 matrix_mautrix_googlechat_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Set up Double Puppeting
 
 If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
 
-### Method 1: automatically, by enabling Appservice Double Puppet or Shared Secret Auth
+### Method 1: automatically, by enabling Shared Secret Auth
 
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service or the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 
-Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
-
-Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
+This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
 
 
 ### Method 2: manually, by asking each user to provide a working access token
@@ -55,3 +49,4 @@ Once logged in, recent chats should show up as new conversations automatically.
 You can learn more about authentication from the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/googlechat/authentication.html).
 
 After successfully enabling bridging, you may wish to [set up Double Puppeting](#set-up-double-puppeting), if you haven't already done so.
+

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

@@ -1,4 +1,4 @@
-# The [Mautrix Hangouts Bridge](https://mau.dev/mautrix/hangouts) is no longer maintained.  It has changed to a [Google Chat Bridge](https://github.com/mautrix/googlechat). Setup instructions for the Google Chat Bridge can be [found here](configuring-playbook-bridge-mautrix-googlechat.md).
+# The [Mautrix Hangouts Bridge](https://mau.dev/mautrix/hangouts) is no longer maintained.  It has changed to a [Google Chat Bridge](https://github.com/mautrix/googlechat). Setup instructions for the Google Chat Bridge can be [found here](configuring-playbook-bridge-mautrix-googlechat.md). 
 
 # Setting up Mautrix Hangouts (optional)
 
@@ -6,17 +6,13 @@ The playbook can install and configure [mautrix-hangouts](https://github.com/mau
 
 See the project's [documentation](https://docs.mau.fi/bridges/python/hangouts/index.html) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
+To enable the [Google Hangouts](https://hangouts.google.com/) bridge just use the following playbook configuration:
 
-To enable the [Google Hangouts](https://hangouts.google.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 matrix_mautrix_hangouts_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Set up Double Puppeting
 
@@ -55,3 +51,4 @@ Once logged in, recent chats should show up as new conversations automatically.
 You can learn more about authentication from the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/hangouts/authentication.html).
 
 After successfully enabling bridging, you may wish to [set up Double Puppeting](#set-up-double-puppeting), if you haven't already done so.
+

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

@@ -1,19 +1,12 @@
 # Setting up Mautrix Instagram (optional)
 
-**Note**: bridging to Facebook [Instagram](https://instagram.com) via this bridge is being [superseded by a new bridge - mautrix-meta](https://github.com/mautrix/facebook/issues/332). For now, the mautrix-instagram bridge continues to work, but the new [mautrix-meta-instagram bridge](./configuring-playbook-bridge-mautrix-meta-instagram.md) is better and more supported. Consider using that bridge instead of this one.
-
 The playbook can install and configure [mautrix-instagram](https://github.com/mautrix/instagram) for you.
 
 See the project's [documentation](https://docs.mau.fi/bridges/python/instagram/index.html) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
 ```yaml
 matrix_mautrix_instagram_enabled: true
 ```
-
 There are some additional things you may wish to configure about the bridge before you continue.
 
 Encryption support is off by default. If you would like to enable encryption, add the following to your `vars.yml` file:
@@ -40,9 +33,6 @@ matrix_mautrix_instagram_configuration_extension_yaml: |
 
 You may wish to look at `roles/custom/matrix-bridge-mautrix-instagram/templates/config.yaml.j2` and `roles/custom/matrix-bridge-mautrix-instagram/defaults/main.yml` to find other things you would like to configure.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 

docs/configuring-playbook-bridge-mautrix-meta-instagram.md

@@ -1,94 +0,0 @@
-# Setting up Instagram bridging via Mautrix Meta (optional)
-
-The playbook can install and configure the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge for you.
-
-Since this bridge component can bridge to both [Messenger](https://messenger.com/) and [Instagram](https://instagram.com/) and you may wish to do both at the same time, the playbook makes it available via 2 different Ansible roles (`matrix-bridge-mautrix-meta-messenger` and `matrix-bridge-mautrix-meta-instagram`). The latter is a reconfigured copy of the first one (created by `just rebuild-mautrix-meta-instagram` and `bin/rebuild-mautrix-meta-instagram.sh`).
-
-This documentation page only deals with the bridge's ability to bridge to Instagram. For bridging to Facebook/Messenger, see [Setting up Messenger bridging via Mautrix Meta](configuring-playbook-bridge-mautrix-meta-messenger.md).
-
-
-## Migrating from the old mautrix-instagram bridge
-
-If you've been using the [mautrix-instagram](./configuring-playbook-bridge-mautrix-instagram.md) bridge, **you'd better get rid of it first** or the 2 bridges will be in conflict:
-
-- both trying to use `@instagrambot:YOUR_DOMAIN` as their username. This conflict may be resolved by adjusting `matrix_mautrix_instagram_appservice_bot_username` or `matrix_mautrix_meta_instagram_appservice_username`
-- both trying to bridge the same DMs
-
-To do so, send a `clean-rooms` command to the management room with the old bridge bot (`@instagrambot:YOUR_DOMAIN`).
-
-This would give you a list of portals and groups of portals you may purge. Proceed with sending commands like `clean recommended`, etc.
-
-Then, consider disabling the old bridge in your configuration, so it won't recreate the portals when you receive new messages.
-
-
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yaml
-matrix_mautrix_meta_instagram_enabled: true
-```
-
-Before proceeding to [re-running the playbook](./installing.md), you may wish to adjust the configuration further. See below.
-
-### Bridge permissions
-
-By default, any user on your homeserver will be able to use the bridge.
-
-Different levels of permission can be granted to users:
-
-- `relay` - Allowed to be relayed through the bridge, no access to commands
-- `user` - Use the bridge with puppeting
-- `admin` - Use and administer the bridge
-
-The permissions are following the sequence: nothing < `relay` < `user` < `admin`.
-
-The default permissions are set via `matrix_mautrix_meta_instagram_bridge_permissions_default` and are somewhat like this:
-```yaml
-matrix_mautrix_meta_instagram_bridge_permissions_default:
-  '*': relay
-  YOUR_DOMAIN: user
-  '{{ matrix_admin }}': admin
-```
-
-If you don't define the `matrix_admin` in your configuration (e.g. `matrix_admin: @user:YOUR_DOMAIN`), then there's no admin by default.
-
-You may redefine `matrix_mautrix_meta_instagram_bridge_permissions_default` any way you see fit, or add extra permissions using `matrix_mautrix_meta_instagram_bridge_permissions_custom` like this:
-
-```yaml
-matrix_mautrix_meta_instagram_bridge_permissions_custom:
-  '@YOUR_USERNAME:YOUR_DOMAIN': admin
-```
-
-You may wish to look at `roles/custom/matrix-bridge-mautrix-meta-instagram/templates/config.yaml.j2` to find more information on the permissions settings and other options you would like to configure.
-
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
-## Set up Double Puppeting
-
-If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
-
-### Method 1: automatically, by enabling Appservice Double Puppet
-
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service for this playbook.
-
-Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
-
-### Method 2: manually, by asking each user to provide a working access token
-
-**Note**: This method for enabling Double Puppeting can be configured only after you've already set up bridging (see [Usage](#usage)).
-
-When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
-
-- retrieve a Matrix access token for yourself. Refer to the documentation on [how to do that](obtaining-access-tokens.md).
-
-- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
-
-- make sure you don't log out the session for which you obtained an access token some time in the future, as that would break the Double Puppeting feature
-
-
-## Usage
-
-You then need to start a chat with `@instagrambot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).

docs/configuring-playbook-bridge-mautrix-meta-messenger.md

@@ -1,108 +0,0 @@
-# Setting up Messenger bridging via Mautrix Meta (optional)
-
-The playbook can install and configure the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge for you.
-
-Since this bridge component can bridge to both [Messenger](https://messenger.com/) and [Instagram](https://instagram.com/) and you may wish to do both at the same time, the playbook makes it available via 2 different Ansible roles (`matrix-bridge-mautrix-meta-messenger` and `matrix-bridge-mautrix-meta-instagram`). The latter is a reconfigured copy of the first one (created by `just rebuild-mautrix-meta-instagram` and `bin/rebuild-mautrix-meta-instagram.sh`).
-
-This documentation page only deals with the bridge's ability to bridge to Facebook Messenger. For bridging to Instagram, see [Setting up Instagram bridging via Mautrix Meta](configuring-playbook-bridge-mautrix-meta-instagram.md).
-
-
-## Migrating from the old mautrix-facebook bridge
-
-If you've been using the [mautrix-facebook](./configuring-playbook-bridge-mautrix-facebook.md) bridge, it's possible to migrate the database using [instructions from the bridge documentation](https://docs.mau.fi/bridges/go/meta/facebook-migration.html) (advanced).
-
-Then you may wish to get rid of the Facebook bridge. To do so, send a `clean-rooms` command to the management room with the old bridge bot (`@facebookbot:YOUR_DOMAIN`).
-
-This would give you a list of portals and groups of portals you may purge. Proceed with sending commands like `clean recommended`, etc.
-
-Then, consider disabling the old bridge in your configuration, so it won't recreate the portals when you receive new messages.
-
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yaml
-matrix_mautrix_meta_messenger_enabled: true
-```
-
-Before proceeding to [re-running the playbook](./installing.md), you may wish to adjust the configuration further. See below.
-
-### Bridge mode
-
-As mentioned above, the [mautrix-meta](https://github.com/mautrix/meta) bridge supports multiple modes of operation.
-The bridge can pull your Messenger messages via 3 different methods:
-
-- (`facebook`) Facebook via `facebook.com`
-- (`facebook-tor`) Facebook via `facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion` ([Tor](https://www.torproject.org/)) - does not currently proxy media downloads
-- (default) (`messenger`) Messenger via `messenger.com` - usable even without a Facebook account
-
-You may switch the mode via the `matrix_mautrix_meta_messenger_meta_mode` variable. The playbook defaults to the `messenger` mode, because it's most universal (every Facebook user has a Messenger account, but the opposite is not true).
-
-Note that switching the mode (especially between `facebook*` and `messenger`) will intentionally make the bridge use another database (`matrix_mautrix_meta_facebook` or `matrix_mautrix_meta_messenger`) to isolate the 2 instances. Switching between Tor and non-Tor may be possible without dataloss, but your mileage may vary. Before switching to a new mode, you may wish to de-configure the old one (send `help` to the bridge bot and unbridge your portals, etc.).
-
-
-### Bridge permissions
-
-By default, any user on your homeserver will be able to use the bridge.
-
-Different levels of permission can be granted to users:
-
-- `relay` - Allowed to be relayed through the bridge, no access to commands
-- `user` - Use the bridge with puppeting
-- `admin` - Use and administer the bridge
-
-The permissions are following the sequence: nothing < `relay` < `user` < `admin`.
-
-The default permissions are set via `matrix_mautrix_meta_messenger_bridge_permissions_default` and are somewhat like this:
-```yaml
-matrix_mautrix_meta_messenger_bridge_permissions_default:
-  '*': relay
-  YOUR_DOMAIN: user
-  '{{ matrix_admin }}': admin
-```
-
-If you don't define the `matrix_admin` in your configuration (e.g. `matrix_admin: @user:YOUR_DOMAIN`), then there's no admin by default.
-
-You may redefine `matrix_mautrix_meta_messenger_bridge_permissions_default` any way you see fit, or add extra permissions using `matrix_mautrix_meta_messenger_bridge_permissions_custom` like this:
-
-```yaml
-matrix_mautrix_meta_messenger_bridge_permissions_custom:
-  '@YOUR_USERNAME:YOUR_DOMAIN': admin
-```
-
-You may wish to look at `roles/custom/matrix-bridge-mautrix-meta-messenger/templates/config.yaml.j2` to find more information on the permissions settings and other options you would like to configure.
-
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
-## Set up Double Puppeting
-
-If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
-
-### Method 1: automatically, by enabling Appservice Double Puppet
-
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service for this playbook.
-
-Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
-
-### Method 2: manually, by asking each user to provide a working access token
-
-**Note**: This method for enabling Double Puppeting can be configured only after you've already set up bridging (see [Usage](#usage)).
-
-When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
-
-- retrieve a Matrix access token for yourself. Refer to the documentation on [how to do that](obtaining-access-tokens.md).
-
-- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
-
-- make sure you don't log out the session for which you obtained an access token some time in the future, as that would break the Double Puppeting feature
-
-
-## Usage
-
-You then need to start a chat with `@messengerbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
-
-You then need to send a `login` command and follow the bridge bot's instructions.
-
-Given that the bot is configured in `messenger` [bridge mode](#bridge-mode) by default, you will need to log in to [messenger.com](https://messenger.com/) (not `facebook.com`!) and obtain the cookies from there as per [the bridge's authentication instructions](https://docs.mau.fi/bridges/go/meta/authentication.html).

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

@@ -6,11 +6,7 @@ See the project's [documentation](https://docs.mau.fi/bridges/python/signal/inde
 
 **Note/Prerequisite**: If you're running with the Postgres database server integrated by the playbook (which is the default), you don't need to do anything special and can easily proceed with installing. However, if you're [using an external Postgres server](configuring-playbook-external-postgres.md), you'd need to manually prepare a Postgres database for this bridge and adjust the variables related to that (`matrix_mautrix_signal_database_*`).
 
-**Note**: This revamped version of the [mautrix-signal (legacy)](configuring-playbook-bridge-mautrix-signal.md) may increase the CPU usage of your homeserver.
-
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Use the following playbook configuration:
 
 ```yaml
 matrix_mautrix_signal_enabled: true
@@ -18,7 +14,14 @@ matrix_mautrix_signal_enabled: true
 
 There are some additional things you may wish to configure about the bridge before you continue.
 
+The relay bot functionality is off by default. If you would like to enable the relay bot, add the following to your `vars.yml` file:
+```yaml
+matrix_mautrix_signal_relaybot_enabled: true
+```
+If you want to activate the relay bot in a room, use `!signal set-relay`.
+Use `!signal unset-relay` to deactivate.
 By default, any user on your homeserver will be able to use the bridge.
+If you enable the relay bot functionality, it will relay every user's messages in a portal room - no matter which homeserver they're from.
 
 Different levels of permission can be granted to users:
 
@@ -43,28 +46,24 @@ matrix_mautrix_signal_configuration_extension_yaml: |
       '@YOUR_USERNAME:YOUR_DOMAIN': admin
 ```
 
-This will add the admin permission to the specific user, while keeping the default permissions.
+This will add the admin permission to the specific user, while keepting the default permissions.
 
 In case you want to replace the default permissions settings **completely**, populate the following item within your `vars.yml` file:
 ```yaml
-matrix_mautrix_signal_bridge_permissions:
+matrix_mautrix_signal_bridge_permissions: |
   '@ADMIN:YOUR_DOMAIN': admin
   '@USER:YOUR_DOMAIN' : user
 ```
 
 You may wish to look at `roles/custom/matrix-bridge-mautrix-signal/templates/config.yaml.j2` to find more information on the permissions settings and other options you would like to configure.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
 ## Set up Double Puppeting
 
 If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
 
-### Method 1: automatically, by enabling Appservice Double Puppet
+### Method 1: automatically, by enabling Shared Secret Auth
 
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service for this playbook.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 
 This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
 

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

@@ -18,9 +18,9 @@ For using this bridge, you would need to authenticate by **providing your userna
 Note that neither of these methods are officially supported by Slack. [matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) uses a Slack bot account which is the only officially supported method for bridging a Slack channel.
 
 
-## Adjusting the playbook configuration
+## Installing
 
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+To enable the bridge, add this to your `vars.yml` file:
 
 ```yaml
 matrix_mautrix_slack_enabled: true
@@ -28,13 +28,7 @@ matrix_mautrix_slack_enabled: true
 
 You may optionally wish to add some [Additional configuration](#additional-configuration), or to [prepare for double-puppeting](#set-up-double-puppeting) before the initial installation.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command:
-
-```
-ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
-```
+After adjusting your `vars.yml` file, re-run the playbook and restart all services: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`
 
 To make use of the bridge, see [Usage](#usage) below.
 
@@ -53,9 +47,9 @@ Take a look at:
 
 If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
 
-#### Method 1: automatically, by enabling Appservice Double Puppet
+#### Method 1: automatically, by enabling Shared Secret Auth
 
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service for this playbook.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 
 This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
 

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

@@ -4,9 +4,7 @@ The playbook can install and configure [mautrix-telegram](https://github.com/mau
 
 See the project's [documentation](https://docs.mau.fi/bridges/python/telegram/index.html) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-You'll need to obtain API keys from [https://my.telegram.org/apps](https://my.telegram.org/apps) and then add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+You'll need to obtain API keys from [https://my.telegram.org/apps](https://my.telegram.org/apps) and then use the following playbook configuration:
 
 ```yaml
 matrix_mautrix_telegram_enabled: true
@@ -14,21 +12,15 @@ matrix_mautrix_telegram_api_id: YOUR_TELEGRAM_APP_ID
 matrix_mautrix_telegram_api_hash: YOUR_TELEGRAM_API_HASH
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
 ## Set up Double Puppeting
 
 If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
 
-### Method 1: automatically, by enabling Appservice Double Puppet or Shared Secret Auth
+### Method 1: automatically, by enabling Shared Secret Auth
 
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service or the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 
-Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
-
-Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
+This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
 
 ### Method 2: manually, by asking each user to provide a working access token
 
@@ -47,7 +39,7 @@ When using this method, **each user** that wishes to enable Double Puppeting nee
 
 You then need to start a chat with `@telegrambot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
 
-If you want to use the relay-bot feature ([relay bot documentation](https://docs.mau.fi/bridges/python/telegram/relay-bot.html)), which allows anonymous user to chat with telegram users, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+If you want to use the relay-bot feature ([relay bot documentation](https://docs.mau.fi/bridges/python/telegram/relay-bot.html)), which allows anonymous user to chat with telegram users, use the following additional playbook configuration:
 
 ```yaml
 matrix_mautrix_telegram_bot_token: YOUR_TELEGRAM_BOT_TOKEN

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

@@ -6,29 +6,20 @@ The playbook can install and configure [mautrix-twitter](https://github.com/maut
 
 See the project's [documentation](https://github.com/mautrix/twitter) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
 ```yaml
 matrix_mautrix_twitter_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Set up Double Puppeting
 
 If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
 
-### Method 1: automatically, by enabling Appservice Double Puppet or Shared Secret Auth
+### Method 1: automatically, by enabling Shared Secret Auth
 
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service or the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 
-Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
-
-Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
+This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
 
 ### Method 2: manually, by asking each user to provide a working access token
 

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

@@ -4,14 +4,11 @@ The playbook can install and configure [mautrix-whatsapp](https://github.com/mau
 
 See the project's [documentation](https://docs.mau.fi/bridges/go/whatsapp/index.html) to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Use the following playbook configuration:
 
 ```yaml
 matrix_mautrix_whatsapp_enabled: true
-```
-
+``` 
 Whatsapp multidevice beta is required, now it is enough if Whatsapp is connected to the Internet every 2 weeks.
 
 The relay bot functionality is off by default. If you would like to enable the relay bot, add the following to your `vars.yml` file:
@@ -27,21 +24,32 @@ matrix_mautrix_whatsapp_bridge_relay_admin_only: false
 If you want to activate the relay bot in a room, use `!wa set-relay`.
 Use `!wa unset-relay` to deactivate.
 
-## Installing
+## Enable backfilling history
+This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
+Note that as of Synapse 1.46, there are still some bugs with the implementation, especially if using event persistence workers.
+Use the following playbook configuration:
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
+```yaml
+matrix_synapse_configuration_extension_yaml: |
+  experimental_features:
+    msc2716_enabled: true
+```
+```yaml
+matrix_mautrix_whatsapp_configuration_extension_yaml:
+  bridge:
+    history_sync:
+      backfill: true
+```
 
 ## Set up Double Puppeting
 
 If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
 
-### Method 1: automatically, by enabling Appservice Double Puppet or Shared Secret Auth
+### Method 1: automatically, by enabling Shared Secret Auth
 
-The bridge will automatically perform Double Puppeting if you enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service or the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 
-Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
-
-Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
+This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
 
 ### Method 2: manually, by asking each user to provide a working access token
 

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

@@ -10,9 +10,10 @@ See the project's [documentation](https://github.com/mautrix/wsproxy#readme) to
 You need to create a `wsproxy.DOMAIN` DNS record pointing to your Matrix server (a `CNAME` pointing to `matrix.DOMAIN`) to use wsproxy.
 The hostname is configurable via a `matrix_mautrix_wsproxy_hostname` variable.
 
-## Adjusting the playbook configuration
 
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+## Configuration
+
+Use the following playbook configuration:
 
 ```yaml
 matrix_mautrix_wsproxy_enabled: true
@@ -26,9 +27,6 @@ matrix_mautrix_wsproxy_syncproxy_shared_secret: 'secret token from bridge'
 
 Note that the tokens must match what is compiled into the [mautrix-imessage](https://github.com/mautrix/imessage) bridge running on your Mac or Android device.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 

docs/configuring-playbook-bridge-mx-puppet-discord.md

@@ -11,17 +11,14 @@ See the project page to learn what it does and why it might be useful to you.
 
 **Note**: we actually use the [Beeper](https://www.beeper.com/)-maintained [fork of mx-puppet-discord](https://gitlab.com/beeper/mx-puppet-monorepo), because `matrix-discord/mx-puppet-discord` is a low-quality and poorly maintained project.
 
-## Adjusting the playbook configuration
+To enable the [Discord](https://discordapp.com/) bridge just use the following
+playbook configuration:
 
-To enable the [Discord](https://discordapp.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 matrix_mx_puppet_discord_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 

docs/configuring-playbook-bridge-mx-puppet-groupme.md

@@ -5,17 +5,14 @@ The playbook can install and configure
 
 See the project page to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
+To enable the [GroupMe](https://groupme.com/) bridge just use the following
+playbook configuration:
 
-To enable the [GroupMe](https://groupme.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 matrix_mx_puppet_groupme_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 

docs/configuring-playbook-bridge-mx-puppet-instagram.md

@@ -5,17 +5,14 @@ The playbook can install and configure
 
 This allows you to bridge Instagram DirectMessages into Matrix.
 
-## Adjusting the playbook configuration
+To enable the [Instagram](https://www.instagram.com/) bridge just use the following
+playbook configuration:
 
-To enable the [Instagram](https://www.instagram.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 matrix_mx_puppet_instagram_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 
@@ -36,3 +33,4 @@ For double-puppeting, you probably want to issue these commands:
 If you are linking only one Instagram account, your `$puppetId` is probably 1, but use the `list` command find out.
 
 The `help` command shows which commands are available, though at the time of writing, not every command is fully implemented.
+

docs/configuring-playbook-bridge-mx-puppet-slack.md

@@ -8,28 +8,25 @@ The playbook can install and configure [Beeper](https://www.beeper.com/)-maintai
 
 See the project page to learn what it does and why it might be useful to you.
 
-## Prerequisite
+## Setup
 
-Follow the [OAuth credentials](https://github.com/Sorunome/mx-puppet-slack#option-2-oauth) instructions to create a new Slack app, setting the redirect URL to `https://matrix.DOMAIN/slack/oauth`.
+To enable the [Slack](https://slack.com/) bridge:
 
-## Adjusting the playbook configuration
-
-To enable the [Slack](https://slack.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yaml
-matrix_mx_puppet_slack_enabled: true
-# Client ID must be quoted so YAML does not parse it as a float.
-matrix_mx_puppet_slack_oauth_client_id: "<SLACK_APP_CLIENT_ID>"
-matrix_mx_puppet_slack_oauth_client_secret: "<SLACK_APP_CLIENT_SECRET>"
-```
-
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command:
-
-```
-ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
-```
+1. Follow the
+   [OAuth credentials](https://github.com/Sorunome/mx-puppet-slack#option-2-oauth)
+   instructions to create a new Slack app, setting the redirect URL to
+   `https://matrix.YOUR_DOMAIN/slack/oauth`.
+2. Update your `vars.yml` with the following:
+    ```yaml
+    matrix_mx_puppet_slack_enabled: true
+    # Client ID must be quoted so YAML does not parse it as a float.
+    matrix_mx_puppet_slack_oauth_client_id: "<SLACK_APP_CLIENT_ID>"
+    matrix_mx_puppet_slack_oauth_client_secret: "<SLACK_APP_CLIENT_SECRET>"
+    ```
+3. Run playbooks with `setup-all` and `start` tags:
+    ```
+    ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
+    ```
 
 ## Usage
 

docs/configuring-playbook-bridge-mx-puppet-steam.md

@@ -5,17 +5,14 @@ The playbook can install and configure
 
 See the project page to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
+To enable the [Steam](https://steampowered.com/) bridge just use the following
+playbook configuration:
 
-To enable the [Steam](https://steampowered.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 matrix_mx_puppet_steam_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 

docs/configuring-playbook-bridge-mx-puppet-twitter.md

@@ -7,13 +7,8 @@ The playbook can install and configure
 
 See the project page to learn what it does and why it might be useful to you.
 
-## Prerequisite
-
-Make an app on [developer.twitter.com](https://developer.twitter.com/en/apps).
-
-## Adjusting the playbook configuration
-
-To enable the [Twitter](https://twitter.com) bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+To enable the [Twitter](https://twitter.com) bridge, make an app on [developer.twitter.com](https://developer.twitter.com/en/apps)
+and fill out the following playbook configuration.
 
 ```yaml
 matrix_mx_puppet_twitter_enabled: true
@@ -24,9 +19,6 @@ matrix_mx_puppet_twitter_access_token_secret: ''
 matrix_mx_puppet_twitter_environment: ''
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 

docs/configuring-playbook-bridge-wechat.md

@@ -1,23 +0,0 @@
-# Setting up the WeChat Bridge (optional)
-
-The playbook can install and configure the [matrix-wechat](https://github.com/duo/matrix-wechat) bridge for you (for bridging to the [WeChat](https://www.wechat.com/) network).
-
-See the project page to learn what it does and why it might be useful to you.
-
-## Adjusting the playbook configuration
-
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yaml
-matrix_wechat_enabled: true
-```
-
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
-## Usage
-
-Once the bridge is installed, start a chat with `@wechatbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
-
-Send `help` to the bot to see the available commands.

docs/configuring-playbook-cactus-comments.md

@@ -1,19 +1,13 @@
 # Setting up Cactus Comments (optional)
 
-The playbook can install and configure the [Cactus Comments](https://cactus.chat) system for you.
+The playbook can install and configure [Cactus Comments](https://cactus.chat) for you.
 
-Cactus Comments is a **federated comment system** built on Matrix. It respects your privacy, and puts you in control.
+Cactus Comments is a **federated comment system** built on Matrix. The role allows you to self-host the system.
+It respects your privacy, and puts you in control.
 
 See the project's [documentation](https://cactus.chat/docs/getting-started/introduction/) to learn what it
 does and why it might be useful to you.
 
-The playbook contains 2 roles for configuring different pieces of the Cactus Comments system:
-
-- `matrix-cactus-comments` - the backend appservice integrating with the Matrix homeserver
-
-- `matrix-cactus-comments-client` - a static website server serving the [cactus-client](https://cactus.chat/docs/client/introduction/) static assets (`cactus.js` and `styles.css`)
-
-You can enable whichever component you need (typically both).
 
 ## Configuration
 
@@ -21,32 +15,26 @@ Add the following block to your `vars.yaml` and make sure to exchange the tokens
 
 ```yaml
 #################
-## Cactus Comments ##
+## Cactus Chat ##
 #################
 
-# This enables the backend (appservice)
 matrix_cactus_comments_enabled: true
 
 # To allow guest comments without users needing to log in, you need to have guest registration enabled.
-# To do this you need to uncomment one of the following lines (depending if you are using Synapse or Dendrite as a homeserver)
-# If you don't know which one you use: The default is Synapse ;)
+# To do this you need to uncomment one of the following lines (depending if you are using synapse or dentrite as a homeserver)
+# If you don't know which one you use: The default is synapse ;)
 # matrix_synapse_allow_guest_access: true
-# matrix_dendrite_allow_guest_access: true
-
-# This enables client assets static files serving on `https://matrix.DOMAIN/cactus-comments`.
-# When the backend (appservice) is enabled, this is also enabled automatically,
-# but we explicitly enable it here.
-matrix_cactus_comments_client_enabled: true
-
-# Uncomment and adjust this part if you'd like to host the client assets at a different location.
-# These variables are only make used if (`matrix_cactus_comments_client_enabled: true`)
-# matrix_cactus_comments_client_hostname: "{{ matrix_server_fqn_matrix }}"
-# matrix_cactus_comments_client_path_prefix: /cactus-comments
+# matrix_dentrite_allow_guest_access: true
 ```
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
+After configuring the playbook, run the [installation](installing.md) command again:
+
+```
+ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
+```
+
 
 ## Usage
 
@@ -60,6 +48,7 @@ Now you are good to go and can include the comment section on your website!
 
 Insert the following snippet into you page and make sure to replace `example.com` with your base domain!
 
+
 ```html
 <script type="text/javascript" src="https://matrix.example.com/cactus-comments/cactus.js"></script>
 <link rel="stylesheet" href="https://matrix.example.com/cactus-comments/style.css" type="text/css">

docs/configuring-playbook-client-cinny.md

@@ -1,29 +1,21 @@
 # Configuring Cinny (optional)
 
 This playbook can install the [cinny](https://github.com/ajbura/cinny) Matrix web client for you.
-Cinny is a web client focusing primarily on simple, elegant and secure interface.
-Cinny can be installed alongside or instead of Element.
+cinny is a web client focusing primarily on simple, elegant and secure interface.
+cinny can be installed alongside or instead of Element.
 
-## DNS
-
-You need to add a `cinny.DOMAIN` DNS record so that Cinny can be accessed.
-By default Cinny will use https://cinny.DOMAIN so you will need to create an CNAME record
-for `cinny`. See [Configuring DNS](configuring-dns.md).
-
-If you would like to use a different domain, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (changing it to use your preferred domain):
-
-```yaml
- matrix_server_fqn_cinny: "app.{{ matrix_domain }}"
-```
-
-## Adjusting the playbook configuration
-
-To enable Cinny, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+If you'd like cinny to be installed, add the following to your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
 
 ```yaml
 matrix_client_cinny_enabled: true
 ```
 
-## Installing
+You will also need to add a DNS record so that cinny can be accessed.
+By default cinny will use https://cinny.DOMAIN so you will need to create an CNAME record
+for `cinny`. See [Configuring DNS](configuring-dns.md).
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
+If you would like to use a different domain, add the following to your configuration file (changing it to use your preferred domain):
+
+```yaml
+ matrix_server_fqn_cinny: "app.{{ matrix_domain }}"
+```

docs/configuring-playbook-client-element.md

@@ -1,6 +1,6 @@
 # Configuring Element (optional)
 
-By default, this playbook installs the [Element](https://github.com/element-hq/element-web) Matrix web client for you.
+By default, this playbook installs the [Element](https://github.com/vector-im/element-web) Matrix client web application.
 If that's okay, you can skip this document.
 
 

docs/configuring-playbook-client-hydrogen.md

@@ -1,29 +1,21 @@
 # Configuring Hydrogen (optional)
 
-This playbook can install the [Hydrogen](https://github.com/element-hq/hydrogen-web) Matrix web client for you.
+This playbook can install the [Hydrogen](https://github.com/vector-im/hydrogen-web) Matrix web client for you.
 Hydrogen is a lightweight web client that supports mobile and legacy web browsers.
 Hydrogen can be installed alongside or instead of Element.
 
-## DNS
-
-You need to add a `hydrogen.DOMAIN` DNS record so that Hydrogen can be accessed.
-By default Hydrogen will use https://hydrogen.DOMAIN so you will need to create an CNAME record
-for `hydrogen`. See [Configuring DNS](configuring-dns.md).
-
-If you would like to use a different domain, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (changing it to use your preferred domain):
-
-```yaml
- matrix_server_fqn_hydrogen: "helium.{{ matrix_domain }}"
-```
-
-## Adjusting the playbook configuration
-
-To enable Hydrogen, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+If you'd like Hydrogen to be installed, add the following to your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
 
 ```yaml
 matrix_client_hydrogen_enabled: true
 ```
 
-## Installing
+You will also need to add a DNS record so that Hydrogen can be accessed. 
+By default Hydrogen will use https://hydrogen.DOMAIN so you will need to create an CNAME record
+for `hydrogen`. See [Configuring DNS](configuring-dns.md).
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
+If you would like to use a different domain, add the following to your configuration file (changing it to use your preferred domain):
+
+```yaml
+ matrix_server_fqn_hydrogen: "helium.{{ matrix_domain }}"
+```

docs/configuring-playbook-client-schildichat.md

@@ -1,55 +1,42 @@
 # Configuring SchildiChat (optional)
 
-This playbook can install the [SchildiChat](https://github.com/SchildiChat/schildichat-desktop) Matrix web client for you.
-SchildiChat is a feature-rich messenger for Matrix based on Element with some extras and tweaks.
-SchildiChat can be installed alongside or instead of Element.
+By default, this playbook does not install the [SchildiChat](https://github.com/SchildiChat/schildichat-desktop) Matrix client web application.
 
-**WARNING**: SchildiChat Web is based on Element-web, but its releases are lagging behind. As an example (from 2024-02-26), SchildiChat Web is 22 releases behind (it being based on element-web `v1.11.36`, while element-web is now on `v1.11.58`). Element-web frequently suffers from security issues, so running something based on an ancient Element-web release is **dangerous**. Use SchildiChat Web at your own risk!
+**WARNING**: SchildiChat is based on Element-web, but its releases are lagging behind. As an example (from 2023-08-31), SchildiChat is 10 releases behind (it being based on element-web `v1.11.30`, while element-web is now on `v1.11.40`). Element-web frequently suffers from security issues, so running something based on an ancient Element-web release is **dangerous**. Use SchildiChat at your own risk!
 
-## DNS
 
-You need to add a `schildichat.DOMAIN` DNS record so that SchildiChat can be accessed.
-By default SchildiChat will use https://schildichat.DOMAIN so you will need to create an CNAME record
-for `schildichat`. See [Configuring DNS](configuring-dns.md).
+## Enabling SchildiChat
 
-If you would like to use a different domain, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (changing it to use your preferred domain):
-
-```yaml
- matrix_server_fqn_schildichat: "sc.{{ matrix_domain }}"
-```
-
-## Adjusting the playbook configuration
-
-To enable SchildiChat, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+If you'd like for the playbook to install SchildiChat, you can enable it in your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
 
 ```yaml
 matrix_client_schildichat_enabled: true
 ```
 
-The playbook provides some customization variables you could use to change SchildiChat's settings.
+
+## Configuring SchildiChat settings
+
+The playbook provides some customization variables you could use to change schildichat's settings.
 
 Their defaults are defined in [`roles/custom/matrix-client-schildichat/defaults/main.yml`](../roles/custom/matrix-client-schildichat/defaults/main.yml) and they ultimately end up in the generated `/matrix/schildichat/config.json` file (on the server). This file is generated from the [`roles/custom/matrix-client-schildichat/templates/config.json.j2`](../roles/custom/matrix-client-schildichat/templates/config.json.j2) template.
 
 **If there's an existing variable** which controls a setting you wish to change, you can simply define that variable in your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`) and [re-run the playbook](installing.md) to apply the changes.
 
-Alternatively, **if there is no pre-defined variable** for a SchildiChat setting you wish to change:
+Alternatively, **if there is no pre-defined variable** for an schildichat setting you wish to change:
 
-- you can either **request a variable to be created** (or you can submit such a contribution yourself). Keep in mind that it's **probably not a good idea** to create variables for each one of SchildiChat's various settings that rarely get used.
+- you can either **request a variable to be created** (or you can submit such a contribution yourself). Keep in mind that it's **probably not a good idea** to create variables for each one of schildichat's various settings that rarely get used.
 
 - or, you can **extend and override the default configuration** ([`config.json.j2`](../roles/custom/matrix-client-schildichat/templates/config.json.j2)) by making use of the `matrix_client_schildichat_configuration_extension_json_` variable. You can find information about this in [`roles/custom/matrix-client-schildichat/defaults/main.yml`](../roles/custom/matrix-client-schildichat/defaults/main.yml).
 
 - or, if extending the configuration is still not powerful enough for your needs, you can **override the configuration completely** using `matrix_client_schildichat_configuration_default` (or `matrix_client_schildichat_configuration`). You can find information about this in [`roles/custom/matrix-client-schildichat/defaults/main.yml`](../roles/custom/matrix-client-schildichat/defaults/main.yml).
 
-### Themes
 
-To change the look of SchildiChat, you can define your own themes manually by using the `matrix_client_schildichat_setting_defaults_custom_themes` setting.
+## Themes
+
+To change the look of schildichat, you can define your own themes manually by using the `matrix_client_schildichat_setting_defaults_custom_themes` setting.
 
 Or better yet, you can automatically pull it all themes provided by the [aaronraimist/element-themes](https://github.com/aaronraimist/element-themes) project by simply flipping a flag (`matrix_client_schildichat_themes_enabled: true`).
 
 If you make your own theme, we encourage you to submit it to the **aaronraimist/element-themes** project, so that the whole community could easily enjoy it.
 
-Note that for a custom theme to work well, all SchildiChat instances that you use must have the same theme installed.
-
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
+Note that for a custom theme to work well, all schildichat instances that you use must have the same theme installed.

docs/configuring-playbook-conduit.md

@@ -1,8 +1,8 @@
 # Configuring Conduit (optional)
 
-By default, this playbook configures the [Synapse](https://github.com/element-hq/synapse) Matrix server, but you can also use [Conduit](https://conduit.rs).
+By default, this playbook configures the [Synapse](https://github.com/matrix-org/synapse) Matrix server, but you can also use [Conduit](https://conduit.rs).
 
-**Notes**:
+**NOTES**:
 
 - **You can't switch an existing Matrix server's implementation** (e.g. Synapse -> Conduit). Proceed below only if you're OK with losing data or you're dealing with a server on a new domain name, which hasn't participated in the Matrix federation yet.
 
@@ -29,11 +29,11 @@ However, since Conduit is difficult (see [famedly/conduit#276](https://gitlab.co
 
 ## Configuring bridges / appservices
 
-Automatic appservice setup is currently unsupported when using Conduit. After setting up the service as usual you may notice that it is unable to start.
+Automatic appservice setup is currently unsupported when using conduit. After setting up the service as usual you may notice that it is unable to start.
 
 You will have to manually register appservices using the the [register-appservice](https://gitlab.com/famedly/conduit/-/blob/next/APPSERVICES.md) command.
 
-Find the `registration.yaml` in the `/matrix` directory, for example `/matrix/mautrix-signal/bridge/registration.yaml`, then pass the content to Conduit:
+Find the `registration.yaml` in the `/matrix` directory, for example `/matrix/mautrix-signal/bridge/registration.yaml`, then pass the content to conduit:
 
 
     @conduit:your.server.name: register-appservice
@@ -55,3 +55,4 @@ Find the `registration.yaml` in the `/matrix` directory, for example `/matrix/ma
     sender_localpart: _bot_signalbot
     url: http://matrix-mautrix-signal:29328
     ```
+

docs/configuring-playbook-dendrite.md

@@ -1,8 +1,8 @@
 # Configuring Dendrite (optional)
 
-By default, this playbook configures the [Synapse](https://github.com/element-hq/synapse) Matrix server, but you can also use [Dendrite](https://github.com/matrix-org/dendrite).
+By default, this playbook configures the [Synapse](https://github.com/matrix-org/synapse) Matrix server, but you can also use [Dendrite](https://github.com/matrix-org/dendrite).
 
-**Notes**:
+**NOTES**:
 
 - **You can't switch an existing Matrix server's implementation** (e.g. Synapse -> Dendrite). Proceed below only if you're OK with losing data or you're dealing with a server on a new domain name, which hasn't participated in the Matrix federation yet.
 
@@ -29,3 +29,4 @@ To use Dendrite, you **generally** need the following additional `vars.yml` conf
 ```yaml
 matrix_homeserver_implementation: dendrite
 ```
+

docs/configuring-playbook-dimension.md

@@ -5,7 +5,7 @@ If you're just installing Matrix services for the first time, please continue wi
 
 **Note**: Dimension is **[officially unmaintained](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2806#issuecomment-1673559299)**. We recommend not bothering with installing it.
 
-**Note**: This playbook now supports running [Dimension](https://dimension.t2bot.io) in both a federated and [unfederated](https://github.com/turt2live/matrix-dimension/blob/master/docs/unfederated.md) environments. This is handled automatically based on the value of `matrix_homeserver_federation_enabled`. Enabling Dimension, means that the `openid` API endpoints will be exposed on the Matrix Federation port (usually `8448`), even if [federation](configuring-playbook-federation.md) is disabled. It's something to be aware of, especially in terms of firewall whitelisting (make sure port `8448` is accessible).
+**Note**: This playbook now supports running [Dimension](https://dimension.t2bot.io) in both a federated and [unfederated](https://github.com/turt2live/matrix-dimension/blob/master/docs/unfederated.md) environments. This is handled automatically based on the value of `matrix_synapse_federation_enabled`. Enabling Dimension, means that the `openid` API endpoints will be exposed on the Matrix Federation port (usually `8448`), even if [federation](configuring-playbook-federation.md) is disabled. It's something to be aware of, especially in terms of firewall whitelisting (make sure port `8448` is accessible).
 
 
 ## Decide on a domain and path

docs/configuring-playbook-email.md

@@ -5,9 +5,9 @@ By default, this playbook sets up an [Exim](https://www.exim.org/) email server
 The email server would attempt to deliver emails directly to their final destination.
 This may or may not work, depending on your domain configuration (SPF settings, etc.)
 
-By default, emails are sent from `matrix@<your-domain-name>` (as specified by the `exim_relay_sender_address` playbook variable).
+By default, emails are sent from `matrix@<your-domain-name>` (as specified by the `matrix_mailer_sender_address` playbook variable).
 
-**Note**: If you are using a Google Cloud instance, [port 25 is always blocked](https://cloud.google.com/compute/docs/tutorials/sending-mail/), so you need to relay email through another SMTP server as described below.
+**Note**: If you are using a Google Cloud instance, [port 25 is always blocked](https://cloud.google.com/compute/docs/tutorials/sending-mail/), so you need to relay email through another SMTP server as described below.   
 
 
 ## Firewall settings
@@ -17,38 +17,39 @@ No matter whether you send email directly (the default) or you relay email throu
 
 ## Relaying email through another SMTP server
 
-If you'd like to relay email through another SMTP server, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
+If you'd like to relay email through another SMTP server, feel free to redefine a few playbook variables.
+Example:
 
 ```yaml
-exim_relay_sender_address: "another.sender@example.com"
-exim_relay_relay_use: true
-exim_relay_relay_host_name: "mail.example.com"
-exim_relay_relay_host_port: 587
-exim_relay_relay_auth: true
-exim_relay_relay_auth_username: "another.sender@example.com"
-exim_relay_relay_auth_password: "some-password"
+matrix_mailer_sender_address: "another.sender@example.com"
+matrix_mailer_relay_use: true
+matrix_mailer_relay_host_name: "mail.example.com"
+matrix_mailer_relay_host_port: 587
+matrix_mailer_relay_auth: true
+matrix_mailer_relay_auth_username: "another.sender@example.com"
+matrix_mailer_relay_auth_password: "some-password"
 ```
 
 **Note**: only the secure submission protocol (using `STARTTLS`, usually on port `587`) is supported. **SMTPS** (encrypted SMTP, usually on port `465`) **is not supported**.
 
 
 ### Configuations for sending emails using Sendgrid
-An easy and free SMTP service to set up is [Sendgrid](https://sendgrid.com/), the free tier allows for up to 100 emails per day to be sent. In the settings below you can provide any email for `exim_relay_sender_address`.
+An easy and free SMTP service to set up is [Sendgrid](https://sendgrid.com/), the free tier allows for up to 100 emails per day to be sent. In the settings below you can provide any email for `matrix_mailer_sender_address`.
 
-The only other thing you need to change is the `exim_relay_relay_auth_password`, which you can generate at https://app.sendgrid.com/settings/api_keys. The API key password looks something like `SG.955oW1mLSfwds7i9Yd6IA5Q.q8GTaB8q9kGDzasegdG6u95fQ-6zkdwrPP8bOeuI`.
+The only other thing you need to change is the `matrix_mailer_relay_auth_password`, which you can generate at https://app.sendgrid.com/settings/api_keys. The API key password looks something like `SG.955oW1mLSfwds7i9Yd6IA5Q.q8GTaB8q9kGDzasegdG6u95fQ-6zkdwrPP8bOeuI`.
 
-Note that the `exim_relay_relay_auth_username` is literally the string `apikey`, it's always the same for Sendgrid.
+Note that the `matrix_mailer_relay_auth_username` is literally the string `apikey`, it's always the same for Sendgrid.
 
 ```yaml
-exim_relay_sender_address: "arbitrary@email.com"
-exim_relay_relay_use: true
-exim_relay_relay_host_name: "smtp.sendgrid.net"
-exim_relay_relay_host_port: 587
-exim_relay_relay_auth: true
-exim_relay_relay_auth_username: "apikey"
-exim_relay_relay_auth_password: "<your api key password>"
+matrix_mailer_sender_address: "arbitrary@email.com"
+matrix_mailer_relay_use: true
+matrix_mailer_relay_host_name: "smtp.sendgrid.net"
+matrix_mailer_relay_host_port: 587
+matrix_mailer_relay_auth: true
+matrix_mailer_relay_auth_username: "apikey"
+matrix_mailer_relay_auth_password: "<your api key password>" 
 ```
 
 ## Troubleshooting
 
-If you're having trouble with email not being delivered, it may be useful to inspect the mailer logs: `journalctl -f -u matrix-exim-relay`.
+If you're having trouble with email not being delivered, it may be useful to inspect the mailer logs: `journalctl -f -u matrix-mailer`.

docs/configuring-playbook-email2matrix.md

@@ -1,6 +1,7 @@
 # Setting up Email2Matrix (optional)
 
-**Note**: email bridging can also happen via the [Postmoogle](configuring-playbook-bot-postmoogle.md) bot supported by the playbook. Postmoogle is much more powerful and easier to use, so we recommend that you use it, instead of Email2Matrix.
+**Note**: email bridging can also happen via the [Postmoogle](configuring-playbook-bot-postmoogle.md) bot supported by the playbook.
+Postmoogle is much more powerful and easier to use, so we recommend that you use it, instead of Email2Matrix.
 
 The playbook can install and configure [email2matrix](https://github.com/devture/email2matrix) for you.
 
@@ -16,34 +17,35 @@ It's not strictly necessary, but you may increase the chances that incoming emai
 ### Port availability
 
 Ensure that port 25 is available on your Matrix server and open in your firewall.
-
 If you have `postfix` or some other email server software installed, you may need to manually remove it first (unless you need it, of course).
 
 If you really need to run an email server on the Matrix machine for other purposes, it may be possible to run Email2Matrix on another port (with a configuration like `matrix_email2matrix_smtp_host_bind_port: "127.0.0.01:2525"`) and have your other email server relay messages there.
-
 For details about using Email2Matrix alongside [Postfix](http://www.postfix.org/), see [here](https://github.com/devture/email2matrix/blob/master/docs/setup_with_postfix.md).
 
 ### Creating a user
 
-Before enabling Email2Matrix, you'd most likely wish to create a dedicated user (or more) that would be sending messages on the Matrix side. Refer to [Registering users](registering-users.md) for ways to do that. A regular (non-admin) user works best.
+Before enabling Email2Matrix, you'd most likely wish to create a dedicated user (or more) that would be sending messages on the Matrix side.
+Refer to [Registering users](registering-users.md) for ways to do that. A regular (non-admin) user works best.
 
 ### Creating a shared room
 
-After creating a sender user, you should create one or more Matrix rooms that you share with that user. It doesn't matter who creates and owns the rooms and who joins later (you or the sender user).
+After creating a sender user, you should create one or more Matrix rooms that you share with that user.
+It doesn't matter who creates and owns the rooms and who joins later (you or the sender user).
 
 What matters is that both you and the sender user are part of the same room and that the sender user has enough privileges in the room to be able to send messages there.
-
 Inviting additional people to the room is okay too.
 
-Take note of each room's room ID (different clients show the room ID in a different place). You'll need the room ID when [configuring the playbook](#adjusting-the-playbook-configuration) below.
+Take note of each room's room id (different clients show the room id in a different place).
+You'll need the room id when doing [Configuration](#configuration) below.
+
 
 ### Obtaining an access token for the sender user
 
 In order for the sender user created above to be able to send messages to the room, we'll need to obtain an access token for it. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
 
-## Adjusting the playbook configuration
+## Configuration
 
-After doing the preparation steps above, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
+After doing the preparation steps above, adjust your `inventory/host_vars/matrix.DOMAIN/vars.yml` configuration like this:
 
 ```yaml
 matrix_email2matrix_enabled: true
@@ -68,10 +70,7 @@ matrix_email2matrix_matrix_mappings:
     SkipMarkdown: true
 ```
 
-You can also set `MatrixHomeserverUrl` to the container URL where your homeserver's Client-Server API lives by using the `{{ matrix_addons_homeserver_client_api_url }}` variable, instead of the public `https://matrix.DOMAIN` endpoint.
+You can also set `MatrixHomeserverUrl` to `http://matrix-synapse-reverse-proxy-companion:8008`, instead of the public `https://matrix.DOMAIN`.
+However, that's more likely to break in the future if you switch to another server implementation than Synapse.
 
-## Installing
-
-To enable Email2Matrix, run the [installation](installing.md) command (`--tags=setup-email2matrix,start`).
-
-After installation, you may wish to send a test email to `my-mailbox@matrix.DOMAIN` to make sure that Email2Matrix works as expected.
+Re-run the playbook (`--tags=setup-email2matrix,start`) and try sending an email to `my-mailbox@matrix.DOMAIN`.

docs/configuring-playbook-etherpad.md

@@ -20,6 +20,16 @@ etherpad_hostname: "{{ matrix_server_fqn_matrix }}"
 etherpad_path_prefix: /etherpad
 ```
 
+**NOTE**: When using the old `matrix-nginx-proxy` reverse-proxy instead of Traefik, you have only 2 choices:
+
+- serving Etherpad at its own dedicated domain:
+  - you need to set the domain using the `matrix_server_fqn_etherpad` variable (not `etherpad_hostname`)
+  - you must use `etherpad_path_prefix: /`
+- serving Etherpad at the [Dimension](configuring-playbook-dimension.md) integration manager's domain (`matrix_server_fqn_dimension`)
+  - you need to have Dimension enabled
+  - you need to add `etherpad_path_prefix: /etherpad` or another prefix (different than `/`)
+  - you need to add `etherpad_nginx_proxy_dimension_integration_enabled: true` to enable this integration
+
 
 ## Adjusting DNS records
 
@@ -28,21 +38,20 @@ Once you've decided on the domain and path, **you may need to adjust your DNS**
 If you've decided to reuse the `matrix.` domain, you won't need to do any extra DNS configuration.
 
 
-## Adjusting the playbook configuration
+## Installing
 
-[Etherpad](https://etherpad.org) installation is disabled by default. To enable Etherpad, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+[Etherpad](https://etherpad.org) installation is disabled by default. You can enable it in your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
 
 ```yaml
 etherpad_enabled: true
 
-# Uncomment and adjust this part if you'd like to enable the admin web UI
-# etherpad_admin_username: YOUR_USERNAME_HERE
-# etherpad_admin_password: YOUR_PASSWORD_HERE
+# Uncomment below to enable the admin web UI
+# etherpad_admin_username: admin
+# etherpad_admin_password: some-password
 ```
 
-## Installing
+Then, [run the installation process](installing.md) again (e.g. `just install-all`).
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Usage
 
@@ -62,13 +71,12 @@ Then from the plugin manager page (`https://etherpad.<your-domain>/admin/plugins
 
 This is how it works in Element, it might work quite similar with other clients:
 
-To integrate a standalone Etherpad in a room, create your pad by visiting `https://etherpad.DOMAIN`. When the pad opens, copy the URL and send a command like this to the room: `/addwidget URL`. You will then find your integrated Etherpad within the right sidebar in the `Widgets` section.
+To integrate a standalone etherpad in a room, create your pad by visiting `https://etherpad.DOMAIN`. When the pad opens, copy the URL and send a command like this to the room: `/addwidget URL`. You will then find your integrated Etherpad within the right sidebar in the `Widgets` section.
 
 
 ### Set Dimension default to the self-hosted Etherpad (optional)
 
 If you decided to install [Dimension integration manager](configuring-playbook-dimension.md) alongside Etherpad, the Dimension administrator users can configure the default URL template.
-
 The Dimension configuration menu can be accessed with the sprocket icon as you begin to add a widget to a room in Element. There you will find the Etherpad Widget Configuration action beneath the _Widgets_ tab.
 
 
@@ -82,5 +90,4 @@ Example: `https://etherpad.<your-domain>/p/$roomId_$padName?showChat=false`
 ## Known issues
 
 If your Etherpad widget fails to load, this might be due to Dimension generating a Pad name so long, the Etherpad app rejects it.
-
 `$roomId_$padName` can end up being longer than 50 characters. You can avoid having this problem by altering the template so it only contains the three word random identifier `$padName`.

docs/configuring-playbook-external-postgres.md

@@ -3,12 +3,14 @@
 By default, this playbook would set up a PostgreSQL database server on your machine, running in a Docker container.
 If that's alright, you can skip this.
 
-**Note**: using **an external Postgres server is currently [not very seamless](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1682#issuecomment-1061461683) when it comes to enabling various other playbook services** - you will need to create a new database/credentials for each service and to point each service to its corresponding database using custom `vars.yml` configuration. **For the best experience with the playbook, stick to using the integrated Postgres server**.
+If you'd like to use an external PostgreSQL server that you manage, you can edit your configuration file  (`inventory/host_vars/matrix.<your-domain>/vars.yml`).
 
-If you'd like to use an external Postgres server that you manage, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
+**NOTE**: using **an external Postgres server is currently [not very seamless](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1682#issuecomment-1061461683) when it comes to enabling various other playbook services** - you will need to create a new database/credentials for each service and to point each service to its corresponding database using custom `vars.yml` configuration. **For the best experience with the playbook, stick to using the integrated Postgres server**.
+
+If you'd like to use an external Postgres server, use a custom `vars.yml` configuration like this:
 
 ```yaml
-postgres_enabled: false
+devture_postgres_enabled: false
 
 # Rewire Synapse to use your external Postgres server
 matrix_synapse_database_host: "your-postgres-server-hostname"

docs/configuring-playbook-federation.md

@@ -6,7 +6,7 @@ That is, people on your server can communicate with people on any other Matrix s
 
 ## Federating only with select servers
 
-To make your server only federate with servers of your choosing, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
+To make your server only federate with servers of your choosing, add this to your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
 
 ```yaml
 matrix_synapse_federation_domain_whitelist:
@@ -33,7 +33,7 @@ matrix_synapse_allow_public_rooms_over_federation: true
 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`):
 
 ```yaml
-matrix_homeserver_federation_enabled: false
+matrix_synapse_federation_enabled: false
 ```
 
 With that, your server's users will only be able to talk among themselves, but not to anyone who is on another server.
@@ -41,11 +41,12 @@ With that, your server's users will only be able to talk among themselves, but n
 **Disabling federation does not necessarily disable the federation port** (`8448`). Services like [Dimension](configuring-playbook-dimension.md) and [ma1sd](configuring-playbook-ma1sd.md) normally rely on `openid` APIs exposed on that port. Even if you disable federation and only if necessary, we may still be exposing the federation port and serving the `openid` APIs there. To override this and completely disable Synapse's federation port use:
 
 ```yaml
-matrix_homeserver_federation_enabled: false
-
 # This stops the federation port on the Synapse side (normally `matrix-synapse:8048` on the container network).
 matrix_synapse_federation_port_enabled: false
 
+# This removes the `8448` virtual host from the matrix-nginx-proxy reverse-proxy server.
+matrix_nginx_proxy_proxy_matrix_federation_api_enabled: false
+
 # This stops the federation port on the synapse-reverse-proxy-companion side (normally `matrix-synapse-reverse-proxy-companion:8048` on the container network).
 matrix_synapse_reverse_proxy_companion_federation_api_enabled: false
 ```
@@ -54,7 +55,6 @@ matrix_synapse_reverse_proxy_companion_federation_api_enabled: false
 
 Why? This change could be useful for people running small Synapse instances on small severs/VPSes to avoid being impacted by a simple DOS/DDOS when bandwidth, RAM, an CPU resources are limited and if your hosting provider does not provide a DOS/DDOS protection.
 
-
 The following changes in the configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`) will allow this and make it possible to proxy the federation through a CDN such as CloudFlare or any other:
 
 ```

docs/configuring-playbook-jitsi.md

@@ -17,17 +17,17 @@ You may also need to open the following ports to your server:
 - `10000/udp` - RTP media over UDP. Depending on your firewall/NAT setup, incoming RTP packets on port `10000` may have the external IP of your firewall as destination address, due to the usage of STUN in JVB (see [`jitsi_jvb_stun_servers`](https://github.com/mother-of-all-self-hosting/ansible-role-jitsi/blob/main/defaults/main.yml)).
 
 
-## Adjusting the playbook configuration
+## Installation
 
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Add this to your `inventory/host_vars/matrix.DOMAIN/vars.yml` configuration:
 
 ```yaml
 jitsi_enabled: true
 
-# Uncomment and adjust this part if you'd like to use a hostname different than the default
+# Uncomment and adjust if you need to use another hostname
 # jitsi_hostname: "jitsi.{{ matrix_domain }}"
 
-# Uncomment and possible adjust this part if you'd like to host under a subpath
+# Uncomment and possible adjust if you'd like to host under a subpath
 # jitsi_path_prefix: /jitsi
 ```
 
@@ -40,7 +40,7 @@ If you're fine with such an open Jitsi instance, please skip to [Apply changes](
 If you would like to control who is allowed to open meetings on your new Jitsi instance, then please follow the following steps to enable Jitsi's authentication and optionally guests mode.
 Currently, there are three supported authentication modes: 'internal' (default), 'matrix' and 'ldap'.
 
-**Note**: Authentication is not tested via the playbook's self-checks.
+**Note:** Authentication is not tested via the playbook's self-checks.
 We therefore recommend that you manually verify if authentication is required by jitsi.
 For this, try to manually create a conference on jitsi.DOMAIN in your browser.
 
@@ -173,8 +173,8 @@ For this role to work you will need an additional section in the ansible hosts f
 <your jvb hosts> ansible_host=<ip address of the jvb host>
 ```
 
-Each JVB will require a server ID to be set so that it can be uniquely identified and this allows Jitsi to keep track of which conferences are on which JVB.
-The server ID is set with the variable `jitsi_jvb_server_id` which ends up as the JVB_WS_SERVER_ID environment variables in the JVB docker container.
+Each JVB will require a server id to be set so that it can be uniquely identified and this allows Jitsi to keep track of which conferences are on which JVB.
+The server id is set with the variable `jitsi_jvb_server_id` which ends up as the JVB_WS_SERVER_ID environment variables in the JVB docker container.
 This variable can be set via the host file, a parameter to the ansible command or in the `vars.yaml` for the host which will have the additional JVB. For example:
 
 ``` yaml
@@ -187,7 +187,7 @@ jvb-2.example.com ansible_host=192.168.0.2 jitsi_jvb_server_id=jvb-2
 jvb-3.example.com ansible_host=192.168.0.3 jitsi_jvb_server_id=jvb-2
 ```
 
-Note that the server ID `jvb-1` is reserved for the JVB instance running on the Matrix host and therefore should not be used as the ID of an additional jvb host.
+Note that the server id `jvb-1` is reserved for the JVB instance running on the Matrix host and therefore should not be used as the id of an additional jvb host.
 
 The additional JVB will also need to expose the colibri web socket port and this can be done with the following variable:
 
@@ -195,7 +195,7 @@ The additional JVB will also need to expose the colibri web socket port and this
 jitsi_jvb_container_colibri_ws_host_bind_port: 9090
 ```
 
-The JVB will also need to know where the prosody xmpp server is located, similar to the server ID this can be set in the vars for the JVB by using the variable
+The JVB will also need to know where the prosody xmpp server is located, similar to the server id this can be set in the vars for the JVB by using the variable
 `jitsi_xmpp_server`. The Jitsi prosody container is deployed on the matrix server by default so the value can be set to the matrix domain. For example:
 
 ```yaml
@@ -227,20 +227,20 @@ To make Traefik reverse-proxy to these additional JVBs (living on other hosts),
 # Traefik proxying for additional JVBs. These can't be configured using Docker
 # labels, like the first JVB is, because they run on different hosts, so we add
 # the necessary configuration to the file provider.
-traefik_provider_configuration_extension_yaml: |
+devture_traefik_provider_configuration_extension_yaml: |
   http:
    routers:
      {% for host in groups['jitsi_jvb_servers'] %}
 
      additional-{{ hostvars[host]['jitsi_jvb_server_id'] }}-router:
        entryPoints:
-         - "{{ traefik_entrypoint_primary }}"
+         - "{{ devture_traefik_entrypoint_primary }}"
        rule: "Host(`{{ jitsi_hostname }}`) && PathPrefix(`/colibri-ws/{{ hostvars[host]['jitsi_jvb_server_id'] }}/`)"
        service: additional-{{ hostvars[host]['jitsi_jvb_server_id'] }}-service
-       {% if traefik_entrypoint_primary != 'web' %}
+       {% if devture_traefik_entrypoint_primary != 'web' %}
 
        tls:
-         certResolver: "{{ traefik_certResolver_primary }}"
+         certResolver: "{{ devture_traefik_certResolver_primary }}"
 
        {% endif %}
 
@@ -271,13 +271,10 @@ jitsi_disable_gravatar: false
 **Beware:** This leaks information to a third party, namely the Gravatar-Service (unless configured otherwise: gravatar.com).
 Besides metadata, this includes the matrix user_id and possibly the room identifier (via `referrer` header).
 
-## Installing
+## Apply changes
 
-After configuring the playbook, run the [installation](installing.md) command:
+Then re-run the playbook: `ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`
 
-```
-ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
-```
 
 ## Usage
 
@@ -289,7 +286,7 @@ You can use the self-hosted Jitsi server in multiple ways:
 
 - **directly (without any Matrix integration)**. Just go to `https://jitsi.DOMAIN`
 
-**Note**: Element apps on mobile devices currently [don't support joining meetings on a self-hosted Jitsi server](https://github.com/element-hq/riot-web/blob/601816862f7d84ac47547891bd53effa73d32957/docs/jitsi.md#mobile-app-support).
+**Note**: Element apps on mobile devices currently [don't support joining meetings on a self-hosted Jitsi server](https://github.com/vector-im/riot-web/blob/601816862f7d84ac47547891bd53effa73d32957/docs/jitsi.md#mobile-app-support).
 
 
 ## Troubleshooting

docs/configuring-playbook-ldap-auth.md

@@ -4,11 +4,11 @@ The playbook can install and configure the [matrix-synapse-ldap3](https://github
 
 See that project's documentation to learn what it does and why it might be useful to you.
 
-If you decide that you'd like to let this playbook install it for you, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
+If you decide that you'd like to let this playbook install it for you, you need some configuration like this:
 
 ```yaml
 matrix_synapse_ext_password_provider_ldap_enabled: true
-matrix_synapse_ext_password_provider_ldap_uri:
+matrix_synapse_ext_password_provider_ldap_uri: 
   - "ldap://ldap-01.mydomain.tld:389"
   - "ldap://ldap-02.mydomain.tld:389"
 matrix_synapse_ext_password_provider_ldap_start_tls: true

docs/configuring-playbook-ma1sd.md

@@ -10,15 +10,14 @@ This server is private by default, potentially at the expense of user discoverab
 
 **Note**: enabling ma1sd, means that the `openid` API endpoints will be exposed on the Matrix Federation port (usually `8448`), even if [federation](configuring-playbook-federation.md) is disabled. It's something to be aware of, especially in terms of firewall whitelisting (make sure port `8448` is accessible).
 
-## Adjusting the playbook configuration
-
-To enable ma1sd, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+To enable ma1sd, use the following additional configuration in your `vars.yml` file:
 
 ```yaml
 matrix_ma1sd_enabled: true
 ```
 
-### Matrix.org lookup forwarding
+
+## Matrix.org lookup forwarding
 
 To ensure maximum discovery, you can make your identity server also forward lookups to the central matrix.org Identity server (at the cost of potentially leaking all your contacts information).
 
@@ -30,14 +29,12 @@ Enabling matrix.org forwarding can happen with the following configuration:
 matrix_ma1sd_matrixorg_forwarding_enabled: true
 ```
 
-### Customizing email templates
+
+## Customizing email templates
 
 If you'd like to change the default email templates used by ma1sd, take a look at the `matrix_ma1sd_threepid_medium_email_custom_` variables
 (in the `roles/custom/matrix-ma1sd/defaults/main.yml` file.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## ma1sd-controlled Registration
 
@@ -47,9 +44,9 @@ To use the [Registration](https://github.com/ma1uta/ma1sd/blob/master/docs/featu
 
 - `matrix_synapse_enable_registration_captcha` - to validate registering users using reCAPTCHA, as described in the [enabling reCAPTCHA](configuring_captcha.md) documentation.
 
-- `matrix_synapse_registrations_require_3pid` - a list of 3pid types (among `'email'`, `'msisdn'`) required by the Synapse server for registering
+- `matrix_synapse_registrations_require_3pid` - to control the types of 3pid (`'email'`, `'msisdn'`) required by the Synapse server for registering
 
-- variables prefixed with `matrix_ma1sd_container_labels_` (e.g. `matrix_ma1sd_container_labels_matrix_client_3pid_registration_enabled`) - to configure the Traefik reverse-proxy to capture and send registration requests to ma1sd (instead of Synapse), so it can apply its additional functionality
+- variables prefixed with `matrix_nginx_proxy_proxy_matrix_3pid_registration_` (e.g. `matrix_nginx_proxy_proxy_matrix_3pid_registration_enabled`) - to configure the integrated nginx webserver to send registration requests to ma1sd (instead of Synapse), so it can apply its additional functionality
 
 - `matrix_ma1sd_configuration_extension_yaml` - to configure ma1sd as required. See the [Registration feature's docs](https://github.com/ma1uta/ma1sd/blob/master/docs/features/registration.md) for inspiration. Also see the [Additional features](#additional-features) section below to learn more about how to use `matrix_ma1sd_configuration_extension_yaml`.
 

docs/configuring-playbook-matrix-corporal.md

@@ -16,9 +16,9 @@ If you decide that you'd like to let this playbook install it for you, you'd nee
 - (optional, but encouraged) [set up the REST authentication password provider module](configuring-playbook-rest-auth.md)
 
 
-## Adjusting the playbook configuration
+## Playbook configuration
 
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
+You would then need some configuration like this:
 
 ```yaml
 # The Shared Secret Auth password provider module is required for Corporal to work.
@@ -52,7 +52,7 @@ matrix_corporal_policy_provider_config: |
 matrix_corporal_http_api_enabled: true
 matrix_corporal_http_api_auth_token: "AUTH_TOKEN_HERE"
 
-# If you need to change matrix-corporal's user ID from the default (matrix-corporal).
+# If you need to change matrix-corporal's user id from the default (matrix-corporal).
 # In any case, you need to make sure this Matrix user is created on your server.
 matrix_corporal_corporal_user_id_local_part: "matrix-corporal"
 
@@ -73,7 +73,7 @@ matrix_synapse_rc_login:
 
 Matrix Corporal operates with a specific Matrix user on your server.
 By default, it's `matrix-corporal` (controllable by the `matrix_corporal_reconciliation_user_id_local_part` setting, see above).
-No matter what Matrix user ID you configure to run it with, make sure that:
+No matter what Matrix user id you configure to run it with, make sure that:
 
 - the Matrix Corporal user is created by [registering it](registering-users.md) **with administrator privileges**. Use a password you remember, as you'll need to log in from time to time to create or join rooms
 
@@ -115,9 +115,7 @@ aux_file_definitions:
 
 To learn more about what the policy configuration, see the matrix-corporal documentation on [policy](https://github.com/devture/matrix-corporal/blob/master/docs/policy.md).
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command (`--tags=setup-all,start` or `--tags=setup-aux-files,setup-corporal,start`).
+Each time you update the policy in your `vars.yml` file, you'd need to re-run the playbook and restart matrix-corporal (`--tags=setup-all,start` or `--tags=setup-aux-files,setup-corporal,start`).
 
 
 ## Matrix Corporal files

docs/configuring-playbook-matrix-ldap-registration-proxy.md

@@ -4,7 +4,7 @@ The playbook can install and configure [matrix-ldap-registration-proxy](https://
 
 This proxy handles Matrix registration requests and forwards them to LDAP.
 
-**Note**: This does support the full Matrix specification for registrations. It only provide a very coarse
+**Please note:** This does support the full Matrix specification for registrations. It only provide a very coarse
 implementation of a basic password registration.
 
 ## Quickstart
@@ -29,11 +29,5 @@ matrix_ldap_registration_proxy_ldap_uri: "{{ matrix_synapse_ext_password_provide
 matrix_ldap_registration_proxy_ldap_base_dn: "{{ matrix_synapse_ext_password_provider_ldap_base }}"
 matrix_ldap_registration_proxy_ldap_user: "{{ matrix_synapse_ext_password_provider_ldap_bind_dn }}"
 matrix_ldap_registration_proxy_ldap_password: "{{ matrix_synapse_ext_password_provider_ldap_bind_password }}"
-
-matrix_ldap_registration_proxy_systemd_wanted_services_list_custom:
-  - matrix-synapse.service
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`

docs/configuring-playbook-matrix-media-repo.md

@@ -23,9 +23,9 @@ matrix_media_repo_enabled: true
 # matrix_media_repo_metrics_enabled: true
 ```
 
-The repo is pre-configured for integrating with the Postgres database, Traefik proxy and [Prometheus/Grafana](configuring-playbook-prometheus-grafana.md) (if metrics enabled) from this playbook for all the available homeserver roles. When the media repo is enabled, other media store roles should be disabled (if using Synapse with other media store roles).
+The repo is pre-configured for integrating with the Postgres database, NGINX proxy and [Prometheus/Grafana](configuring-playbook-prometheus-grafana.md) (if metrics enabled) from this playbook for all the available homeserver roles. When the media repo is enabled, other media store roles should be disabled (if using Synapse with other media store roles).
 
-By default, the media-repo will use the local filesystem for data storage. You can alternatively use a `s3` cloud backend as well. Access token caching is also enabled by default since the logout endpoints are proxied through the media repo.
+By default, the media-repo will use the local filesystem for data storage. Additional options include `s3` and `IPFS` (experimental). Access token caching is also enabled by default since the logout endpoints are proxied through the media repo.
 
 ## Configuring the media-repo
 
@@ -43,72 +43,74 @@ matrix_media_repo_database_max_connections: 25
 matrix_media_repo_database_max_idle_connections: 5
 
 # These users have full access to the administrative functions of the media repository.
-# See docs/admin.md for information on what these people can do. They must belong to one of the
-# configured homeservers above.
-# matrix_media_repo_admins: [
-#   "@your_username:example.org"
-# ]
+# See https://github.com/turt2live/matrix-media-repo/blob/release-v1.2.8/docs/admin.md for 
+# information on what these people can do. They must belong to one of the configured 
+# homeservers above.
+matrix_media_repo_admins:
+  admins: []
+# admins:
+#   - "@your_username:example.org"
 
-matrix_media_repo_admins: []
+# Datastores are places where media should be persisted. This isn't dedicated for just uploads:
+# thumbnails and other misc data is also stored in these places. The media repo, when looking
+# for a datastore to use, will always use the smallest datastore first.
+matrix_media_repo_datastores:
+  datastores:
+    - type: file
+      enabled: true # Enable this to set up data storage.
+      # Datastores can be split into many areas when handling uploads. Media is still de-duplicated
+      # across all datastores (local content which duplicates remote content will re-use the remote
+      # content's location). This option is useful if your datastore is becoming very large, or if
+      # you want faster storage for a particular kind of media.
+      #
+      # The kinds available are:
+      #   thumbnails    - Used to store thumbnails of media (local and remote).
+      #   remote_media  - Original copies of remote media (servers not configured by this repo).
+      #   local_media   - Original uploads for local media.
+      #   archives      - Archives of content (GDPR and similar requests).
+      forKinds: ["thumbnails", "remote_media", "local_media", "archives"]
+      opts:
+        path: /data/media
 
-# Datastores can be split into many areas when handling uploads. Media is still de-duplicated
-# across all datastores (local content which duplicates remote content will re-use the remote
-# content's location). This option is useful if your datastore is becoming very large, or if
-# you want faster storage for a particular kind of media.
-#
-# To disable this datastore, making it readonly, specify `forKinds: []`.
-#
-# The kinds available are:
-#   thumbnails    - Used to store thumbnails of media (local and remote).
-#   remote_media  - Original copies of remote media (servers not configured by this repo).
-#   local_media   - Original uploads for local media.
-#   archives      - Archives of content (GDPR and similar requests).
-matrix_media_repo_datastore_file_for_kinds: ["thumbnails", "remote_media", "local_media", "archives"]
-matrix_media_repo_datastore_s3_for_kinds: []
+    - type: s3
+      enabled: false # Enable this to set up s3 uploads
+      forKinds: ["thumbnails", "remote_media", "local_media", "archives"]
+      opts:
+        # The s3 uploader needs a temporary location to buffer files to reduce memory usage on
+        # small file uploads. If the file size is unknown, the file is written to this location
+        # before being uploaded to s3 (then the file is deleted). If you aren't concerned about
+        # memory usage, set this to an empty string.
+        tempPath: "/tmp/mediarepo_s3_upload"
+        endpoint: sfo2.digitaloceanspaces.com
+        accessKeyId: ""
+        accessSecret: ""
+        ssl: true
+        bucketName: "your-media-bucket"
+        # An optional region for where this S3 endpoint is located. Typically not needed, though
+        # some providers will need this (like Scaleway). Uncomment to use.
+        #region: "sfo2"
+        # An optional storage class for tuning how the media is stored at s3.
+        # See https://aws.amazon.com/s3/storage-classes/ for details; uncomment to use.
+        #storageClass: STANDARD
 
-# The s3 uploader needs a temporary location to buffer files to reduce memory usage on
-# small file uploads. If the file size is unknown, the file is written to this location
-# before being uploaded to s3 (then the file is deleted). If you aren't concerned about
-# memory usage, set this to an empty string.
-matrix_media_repo_datastore_s3_opts_temp_path: ""
-matrix_media_repo_datastore_s3_opts_endpoint: "sfo2.digitaloceanspaces.com"
-matrix_media_repo_datastore_s3_opts_access_key_id: ""
-matrix_media_repo_datastore_s3_opts_access_secret: ""
-matrix_media_repo_datastore_s3_opts_ssl: true
-matrix_media_repo_datastore_s3_opts_bucket_name: "your-media-bucket"
-
-# An optional region for where this S3 endpoint is located. Typically not needed, though
-# some providers will need this (like Scaleway). Uncomment to use.
-# matrix_media_repo_datastore_s3_opts_region: "sfo2"
-
-# An optional storage class for tuning how the media is stored at s3.
-# See https://aws.amazon.com/s3/storage-classes/ for details; uncomment to use.
-# matrix_media_repo_datastore_s3_opts_storage_class: "STANDARD"
+    # The media repo does support an IPFS datastore, but only if the IPFS feature is enabled. If
+    # the feature is not enabled, this will not work. Note that IPFS support is experimental at
+    # the moment and not recommended for general use.
+    #
+    # NOTE: Everything you upload to IPFS will be publicly accessible, even when the media repo
+    # puts authentication on the download endpoints. Only use this option for cases where you
+    # expect your media to be publicly accessible.
+    - type: ipfs
+      enabled: false # Enable this to use IPFS support
+      forKinds: ["local_media"]
+      # The IPFS datastore currently has no options. It will use the daemon or HTTP API configured
+      # in the IPFS section of your main config.
+      opts: {}
 
 ```
 
 Full list of configuration options with documentation can be found in [`roles/custom/matrix-media-repo/defaults/main.yml`](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/roles/custom/matrix-media-repo/defaults/main.yml)
 
-## Signing Keys
-
-Authenticated media endpoints ([MSC3916](https://github.com/matrix-org/matrix-spec-proposals/pull/3916)) requires MMR to have a configured signing key to authorize outbound federation requests. Additionally, the signing key must be merged with your homeserver's signing key file.
-
-The playbook default is to generate a MMR signing key when invoking the setup role and merge it with your homeserver if you are using Synapse or Dendrite. This can be disabled if desired by setting the option in your inventory:
-
-```yaml
-matrix_media_repo_generate_signing_key: false
-```
-
-If you wish to manually generate the signing key and merge it with your homeserver's signing key file, see https://docs.t2bot.io/matrix-media-repo/v1.3.5/installation/signing-key/ for more details.
-
-**Note that if you uninstall MMR from the playbook, it will not remove the old MMR signing key from your homeserver's signing key file. You will have to remove it manually.**
-
-### Key backup and revoking
-
-Since your homeserver signing key file is modified by the playbook, a backup will be created in `HOMESERVER_DIR/config/DOMAIN.signing.key.backup`. If you need to remove/revoke old keys, you can restore from this backup or remove the MMR key ID from your `DOMAIN.signing.key` file.
-
-Additionally, its recommended after revoking a signing key to update your homeserver config file (`old_signing_keys` field for Synapse and `old_private_keys` for Dendrite). See your homeserver config file for further documentation on how to populate the field.
-
 ## Importing data from an existing media store
 
 If you want to add this repo to an existing homeserver managed by the playbook, you will need to import existing media into MMR's database or you will lose access to older media while it is active. MMR versions up to `v1.3.3` only support importing from Synapse, but newer versions (at time of writing: only `latest`) also support importing from Dendrite.
@@ -123,7 +125,7 @@ To import the Synapse media store, you're supposed to invoke the `import_synapse
 
 This guide here is adapted from the [upstream documentation about the import_synapse script](https://github.com/turt2live/matrix-media-repo#importing-media-from-synapse).
 
-Run the following command on the server (after replacing `postgres_connection_password` in it with the value found in your `vars.yml` file):
+Run the following command on the server (after replacing `devture_postgres_connection_password` in it with the value found in your `vars.yml` file):
 
 ```sh
 docker exec -it matrix-media-repo \
@@ -132,7 +134,7 @@ docker exec -it matrix-media-repo \
         -dbHost matrix-postgres \
         -dbPort 5432 \
         -dbUsername matrix \
-        -dbPassword postgres_connection_password
+        -dbPassword devture_postgres_connection_password
 ```
 
 Enter `1` for the Machine ID when prompted (you are not doing any horizontal scaling) unless you know what you're doing.
@@ -145,7 +147,7 @@ If you're using the [Dendrite](configuring-playbook-dendrite.md) homeserver inst
 
 To import the Dendrite media store, you're supposed to invoke the `import_dendrite` tool which is part of the matrix-media-repo container image. Your Dendrite database is called `dendrite_mediaapi` by default, unless you've changed it by modifying `matrix_dendrite_media_api_database`.
 
-Run the following command on the server (after replacing `postgres_connection_password` in it with the value found in your `vars.yml` file):
+Run the following command on the server (after replacing `devture_postgres_connection_password` in it with the value found in your `vars.yml` file):
 
 ```sh
 docker exec -it matrix-media-repo \
@@ -154,7 +156,7 @@ docker exec -it matrix-media-repo \
         -dbHost matrix-postgres \
         -dbPort 5432 \
         -dbUsername matrix \
-        -dbPassword postgres_connection_password
+        -dbPassword devture_postgres_connection_password
 ```
 
 Enter `1` for the Machine ID when prompted (you are not doing any horizontal scaling) unless you know what you're doing.

docs/configuring-playbook-matrix-registration.md

@@ -17,20 +17,18 @@ Use matrix-registration to **create unique registration links**, which people ca
 - **a user registration page**, where people can use these registration tokens. By default, exposed at `https://matrix.DOMAIN/matrix-registration`
 
 
-## Adjusting the playbook configuration
+## Installing
 
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Adjust your playbook configuration (your `inventory/host_vars/matrix.DOMAIN/vars.yml` file):
 
 ```yaml
 matrix_registration_enabled: true
 
-# Generate a strong secret here. Consider generating it with `pwgen -s 64 1`
+# Generate a strong secret using: `pwgen -s 64 1`.
 matrix_registration_admin_secret: "ENTER_SOME_SECRET_HERE"
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command:
+Then, run the [installation](installing.md) command again:
 
 ```
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start

docs/configuring-playbook-mautrix-bridges.md

@@ -5,23 +5,24 @@ This is a common guide for configuring mautrix bridges.
 
 You can see each bridge's features at in the `ROADMAP.md` file in its corresponding [mautrix](https://github.com/mautrix) repository.
 
-## Adjusting the playbook configuration
+To enable a bridge add:
 
-To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 # Replace SERVICENAME with one of: twitter, facebook, instagram, ..
 matrix_mautrix_SERVICENAME_enabled: true
 ```
 
+to your `vars.yml`
+
 There are some additional things you may wish to configure about the bridge before you continue. Each bridge may have additional requirements besides `_enabled: true`. For example, the mautrix-telegram bridge (our documentation page about it is [here](configuring-playbook-bridge-mautrix-telegram.md)) requires the `matrix_mautrix_telegram_api_id` and `matrix_mautrix_telegram_api_hash` variables to be defined. Refer to each bridge's individual documentation page for details about enabling bridges.
 
-To **configure a user as an administrator for all bridges**, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+You can add
 
 ```yaml
 matrix_admin: "@YOUR_USERNAME:{{ matrix_domain }}"
 ```
-
+to `vars.yml` to **configure a user as an administrator for all bridges**.
 **Alternatively** (more verbose, but allows multiple admins to be configured), you can do the same on a per-bridge basis with:
 
 ```yaml
@@ -33,25 +34,27 @@ matrix_mautrix_SERVICENAME_configuration_extension_yaml: |
 
 ## encryption
 
-Encryption support is off by default. If you would like to enable encryption, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Encryption support is off by default. If you would like to enable encryption, add the following to your `vars.yml` file:
 
 **for all bridges with encryption support**:
 
 ```yaml
 matrix_bridges_encryption_enabled: true
-matrix_bridges_encryption_default: true
 ```
 
 **Alternatively**, for a specific bridge:
 
 ```yaml
-matrix_mautrix_SERVICENAME_bridge_encryption_enabled: true
-matrix_mautrix_SERVICENAME_bridge_encryption_default: true
+matrix_mautrix_SERVICENAME_configuration_extension_yaml: |
+  bridge:
+    encryption:
+      allow: true
+      default: true
 ```
 
 ## relay mode
 
-Relay mode is off by default. If you would like to enable relay mode, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Relay mode is off by default. If you would like to enable relay mode, add the following to your `vars.yml` file:
 
 **for all bridges with relay mode support**:
 
@@ -92,20 +95,22 @@ Can be used to set the username for the bridge.
 
 You may wish to look at `roles/custom/matrix-bridge-mautrix-SERVICENAME/templates/config.yaml.j2` and `roles/custom/matrix-bridge-mautrix-SERVICENAME/defaults/main.yml` to find other things you would like to configure.
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
 
 ## Set up Double Puppeting
 
-To set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service for this playbook.
+To set up  [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html)
+
+please do so automatically, by enabling Shared Secret Auth
 
 The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook by adding
 
 ```yaml
-matrix_appservice_double_puppet_enabled: true
+matrix_synapse_ext_password_provider_shared_secret_auth_enabled: true
+matrix_synapse_ext_password_provider_shared_secret_auth_shared_secret: YOUR_SHARED_SECRET_GOES_HERE
 ```
 
+You should generate a strong shared secret with a command like this: pwgen -s 64 1
+
 This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
 
 ## Controlling the logging level
@@ -114,7 +119,7 @@ This is the recommended way of setting up Double Puppeting, as it's easier to ac
 matrix_mautrix_SERVICENAME_logging_level: WARN
 ```
 
-to `vars.yml` to control the logging level, where you may replace WARN with one of the following to control the verbosity of the logs generated: TRACE, DEBUG, INFO, WARN, ERROR, or FATAL.
+to `vars.yml` to control the logging level, where you may replace WARN with one of the following to control the verbosity of the logs generated:     TRACE, DEBUG, INFO, WARN, ERROR, or FATAL.
 
 If you have issues with a service, and are requesting support, the higher levels of logging will generally be more helpful.
 

docs/configuring-playbook-nginx.md

@@ -1,3 +1,83 @@
 # Configure Nginx (optional, advanced)
 
-Since 2024-01, this playbook no longer uses nginx as its reverse-proxy.
+**Note**: the playbook is [in the process of moving to Traefik](../CHANGELOG.md#reverse-proxy-configuration-changes-and-initial-traefik-support). Traefik is already the default reverse-proxy for new installations and existing users are also strongly encouraged to switch to Traefik. As such, this **nginx documentation below may be incomplete or misleading**.
+
+
+## Using Nginx status
+
+This will serve a statuspage to the hosting machine only. Useful for monitoring software like [longview](https://www.linode.com/docs/platform/longview/longview-app-for-nginx/)
+
+```yaml
+matrix_nginx_proxy_proxy_matrix_nginx_status_enabled: true
+```
+
+This will serve the status page under the following addresses:
+- `http://matrix.DOMAIN/nginx_status` (using HTTP)
+- `https://matrix.DOMAIN/nginx_status` (using HTTPS)
+
+By default, if ```matrix_nginx_proxy_nginx_status_enabled``` is enabled, access to the status page would be allowed from the local IP address of the server. If you wish to allow access from other IP addresses, you can provide them as a list:
+
+```yaml
+matrix_nginx_proxy_proxy_matrix_nginx_status_allowed_addresses:
+- 8.8.8.8
+- 1.1.1.1
+```
+
+## Adjusting SSL in your server
+
+You can adjust how the SSL is served by the nginx server using the `matrix_nginx_proxy_ssl_preset` variable. We support a few presets, based on the Mozilla Server Side TLS
+Recommended configurations. These presets influence the TLS Protocol, the SSL Cipher Suites and the `ssl_prefer_server_ciphers` variable of nginx.
+Possible values are:
+
+- `"modern"` - For Modern clients that support TLS 1.3, with no need for backwards compatibility
+- `"intermediate"` (**default**) - Recommended configuration for a general-purpose server
+- `"old"` - Services accessed by very old clients or libraries, such as Internet Explorer 8 (Windows XP), Java 6, or OpenSSL 0.9.8
+
+**Be really carefull when setting it to `"modern"`**. This could break comunication with other Matrix servers, limiting your federation posibilities.
+
+Besides changing the preset (`matrix_nginx_proxy_ssl_preset`), you can also directly override these 3 variables:
+
+- `matrix_nginx_proxy_ssl_protocols`: for specifying the supported TLS protocols.
+- `matrix_nginx_proxy_ssl_prefer_server_ciphers`: for specifying if the server or the client choice when negotiating the cipher. It can set to `on` or `off`.
+- `matrix_nginx_proxy_ssl_ciphers`: for specifying the SSL Cipher suites used by nginx.
+
+For more information about these variables, check the `roles/custom/matrix-nginx-proxy/defaults/main.yml` file.
+
+## Synapse + OpenID Connect for Single-Sign-On
+
+If you want to use OpenID Connect as an SSO provider (as per the [Synapse OpenID docs](https://github.com/matrix-org/synapse/blob/develop/docs/openid.md)), you need to use the following configuration (in your `vars.yml` file) to instruct nginx to forward `/_synapse/oidc` to Synapse:
+
+```yaml
+matrix_nginx_proxy_proxy_matrix_client_api_forwarded_location_synapse_oidc_api_enabled: true
+```
+
+## Disable Nginx access logs
+
+This will disable the access logging for nginx.
+
+```yaml
+matrix_nginx_proxy_access_log_enabled: false
+```
+
+## Additional configuration
+
+This playbook also allows for additional configuration to be applied to the nginx server.
+
+If you want this playbook to obtain and renew certificates for other domains, then you can set the `matrix_ssl_additional_domains_to_obtain_certificates_for` variable (as mentioned in the [Obtaining SSL certificates for additional domains](configuring-playbook-ssl-certificates.md#obtaining-ssl-certificates-for-additional-domains) documentation as well). Make sure that you have set the DNS configuration for the domains you want to include to point at your server.
+
+```yaml
+matrix_ssl_additional_domains_to_obtain_certificates_for:
+  - domain.one.example
+  - domain.two.example
+```
+
+You can include additional nginx configuration by setting the `matrix_nginx_proxy_proxy_http_additional_server_configuration_blocks` variable.
+
+```yaml
+matrix_nginx_proxy_proxy_http_additional_server_configuration_blocks:
+  - |
+    # These lines will be included in the nginx configuration.
+    # This is at the top level of the file, so you will need to define all of the `server { ... }` blocks.
+  - |
+    # For advanced use, have a look at the template files in `roles/custom/matrix-nginx-proxy/templates/nginx/conf.d`
+```

docs/configuring-playbook-ntfy.md

@@ -17,7 +17,8 @@ Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.
 # Enabling it is the only required setting
 ntfy_enabled: true
 
-# Uncomment and adjust this part if you'd like to use a hostname different than the default
+# This is the default hostname.
+# Uncomment the line below and change it, if you'd like.
 # matrix_server_fqn_ntfy: "ntfy.{{ matrix_domain }}"
 
 # Uncomment to enable the ntfy web app (disabled by default)
@@ -28,7 +29,7 @@ ntfy_enabled: true
 #   log_level: DEBUG
 ```
 
-For a more complete list of variables that you could override, see the [`defaults/main.yml` file](https://github.com/mother-of-all-self-hosting/ansible-role-ntfy/-/blob/main/defaults/main.yml) of the ntfy Ansible role.
+For a more complete list of variables that you could override, see the [`defaults/main.yml` file](https://gitlab.com/etke.cc/roles/ntfy/-/blob/main/defaults/main.yml) of the ntfy Ansible role.
 
 For a complete list of ntfy config options that you could put in `ntfy_configuration_extension_yaml`, see the [ntfy config documentation](https://ntfy.sh/docs/config/#config-options).
 
@@ -37,7 +38,7 @@ For a complete list of ntfy config options that you could put in `ntfy_configura
 
 Don't forget to add `ntfy.<your-domain>` to DNS as described in [Configuring DNS](configuring-dns.md) before running the playbook.
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start

docs/configuring-playbook-own-webserver.md

@@ -1,64 +1,51 @@
 # Using your own webserver, instead of this playbook's Traefik reverse-proxy (optional, advanced)
 
-By default, this playbook installs its own [Traefik](https://traefik.io/) reverse-proxy server (in a Docker container) which listens on ports 80 and 443.
+**Note**: the playbook is [in the process of moving to Traefik](../CHANGELOG.md#reverse-proxy-configuration-changes-and-initial-traefik-support). The **documentation below may be incomplete or misleading**.
 
+By default, this playbook installs its own nginx webserver (called `matrix-nginx-proxy`, in a Docker container) which listens on ports 80 and 443.
 If that's alright, you can skip this.
 
+Soon, this default will change and the playbook will install its own [Traefik](https://traefik.io/) reverse-proxy instead.
+
 ## Traefik
 
-[Traefik](https://traefik.io/) is the default reverse-proxy for the playbook since [2023-02-26](../CHANGELOG.md/#2023-02-26) and serves **2 purposes**:
-
-- serving public traffic and providing SSL-termination with certificates obtained from [Let's Encrypt](https://letsencrypt.org/). See [Adjusting SSL certificate retrieval](./configuring-playbook-ssl-certificates.md).
-
-- assists internal communication between addon services (briges, bots, etc.) and the homeserver via an internal entrypoint (`matrix-internal-matrix-client-api`).
+[Traefik](https://traefik.io/) will be the default reverse-proxy for the playbook in the near future.
 
 There are 2 ways to use Traefik with this playbook, as described below.
 
 ### Traefik managed by the playbook
 
-To have the playbook install and use Traefik, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+To switch to Traefik now, use configuration like this:
 
 ```yaml
 matrix_playbook_reverse_proxy_type: playbook-managed-traefik
 
-traefik_config_certificatesResolvers_acme_email: YOUR_EMAIL_ADDRESS
+devture_traefik_config_certificatesResolvers_acme_email: YOUR_EMAIL_ADDRESS
 ```
 
-Traefik will manage SSL certificates for all services seamlessly.
+This will install Traefik in the place of `matrix-nginx-proxy`. Traefik will manage SSL certificates for all services seamlessly.
 
+**Note**: during the transition period, `matrix-nginx-proxy` will still be installed in local-only mode. Do not be alarmed to see `matrix-nginx-proxy` running even when you've chosen Traefik as your reverse-proxy. In the future, we'll be able to run without nginx, but we're not there yet.
 
 ### Traefik managed by you
 
 ```yaml
 matrix_playbook_reverse_proxy_type: other-traefik-container
 
-# Uncomment and adjust this part if your Traefik container is on another network
-# matrix_playbook_reverse_proxy_container_network: traefik
+matrix_playbook_reverse_proxyable_services_additional_network: your-traefik-network
 
-# Adjust to point to your Traefik container
-matrix_playbook_reverse_proxy_hostname: name-of-your-traefik-container
-
-traefik_certs_dumper_ssl_dir_path: "/path/to/your/traefiks/acme.json/directory"
-
-# Uncomment and adjust the variable below if the name of your federation entrypoint is different
-# than the default value (matrix-federation).
-# matrix_federation_traefik_entrypoint_name: matrix-federation
+devture_traefik_certs_dumper_ssl_dir_path: "/path/to/your/traefiks/acme.json/directory"
 ```
 
 In this mode all roles will still have Traefik labels attached. You will, however, need to configure your Traefik instance and its entrypoints.
 
-By default, the playbook configured a `default` certificate resolver and multiple entrypoints.
+By default, the playbook congiures services use a `web-secure` (443) and `matrix-federation` (8448) entrypoints, as well as a `default` certificate resolver.
 
-You need to configure 4 entrypoints for your Traefik server:
-
-- `web` (TCP port `80`) - used for redirecting to HTTPS (`web-secure`)
-- `web-secure` (TCP port `443`) - used for exposing the Matrix Client-Server API and all other services
-- `matrix-federation` (TCP port `8448`) - used for exposing the Matrix Federation API
-- `matrix-internal-matrix-client-api` (TCP port `8008`) - used internally for addon services (bridges, bots) to communicate with the homserver
+You need to configure 3 entrypoints for your Traefik server: `web` (TCP port `80`), `web-secure` (TCP port `443`) and `matrix-federation` (TCP port `8448`).
 
 Below is some configuration for running Traefik yourself, although we recommend using [Traefik managed by the playbook](#traefik-managed-by-the-playbook).
 
-Note that this configuration on its own does **not** redirect traffic on port 80 (plain HTTP) to port 443 for HTTPS. If you are not already doing this in Traefik, it can be added to Traefik in a [file provider](https://docs.traefik.io/v2.0/providers/file/) as follows:
+Note that this configuration on its own does **not** redirect traffic on port 80 (plain HTTP) to port 443 for HTTPS, which may cause some issues, since the built-in Nginx proxy usually does this. If you are not already doing this in Traefik, it can be added to Traefik in a [file provider](https://docs.traefik.io/v2.0/providers/file/) as follows:
 
 ```toml
 [http]
@@ -97,8 +84,7 @@ services:
       - "--providers.docker.network=traefik"
       - "--providers.docker.exposedbydefault=false"
       - "--entrypoints.web-secure.address=:443"
-      - "--entrypoints.matrix-federation.address=:8448"
-      - "--entrypoints.matrix-internal-matrix-client-api.address=:8008"
+      - "--entrypoints.federation.address=:8448"
       - "--certificatesresolvers.default.acme.tlschallenge=true"
       - "--certificatesresolvers.default.acme.email=YOUR EMAIL"
       - "--certificatesresolvers.default.acme.storage=/letsencrypt/acme.json"
@@ -116,15 +102,15 @@ networks:
 
 ## Another webserver
 
-If you don't wish to use Traefik, you can also use your own webserver.
+If you don't wish to use Traefik or `matrix-nginx-proxy`, you can also use your own webserver.
 
 Doing this is possible, but requires manual work.
 
 There are 2 ways to go about it:
 
-- (recommended) [Fronting the integrated reverse-proxy webserver with another reverse-proxy](#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) - using the playbook-managed reverse-proxy (Traefik), but disabling SSL termination for it, exposing this reverse-proxy on a few local ports (e.g. `127.0.0.1:81`, etc.) and forwarding traffic from your own webserver to those few ports
+- (recommended) [Fronting the integrated reverse-proxy webserver with another reverse-proxy](#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) - using a playbook-managed reverse-proxy (either `matrix-nginx-proxy` or Traefik), disabling SSL termination for it, exposing this reverse-proxy on a few local ports (e.g. `127.0.0.1:81`, etc.) and forwarding traffic from your own webserver to those few ports
 
-- (difficult) [Using no reverse-proxy on the Matrix side at all](#using-no-reverse-proxy-on-the-matrix-side-at-all) disabling the playbook-managed reverse-proxy (Traefik), exposing services one by one using `_host_bind_port` variables and forwarding traffic from your own webserver to those ports
+- (difficult) [Using no reverse-proxy on the Matrix side at all](#using-no-reverse-proxy-on-the-matrix-side-at-all) disabling all playbook-managed reverse-proxies (no `matrix-nginx-proxy`, no Traefik)
 
 
 ### Fronting the integrated reverse-proxy webserver with another reverse-proxy
@@ -133,9 +119,9 @@ This method is about leaving the integrated reverse-proxy webserver be, but maki
 
 If you wish to use another webserver, the integrated reverse-proxy webserver usually gets in the way because it attempts to fetch SSL certificates and binds to ports 80, 443 and 8448 (if Matrix Federation is enabled).
 
-You can disable such behavior and make the integrated reverse-proxy webserver only serve traffic locally on the host itself (or over a local network).
+You can disable such behavior and make the integrated reverse-proxy webserver only serve traffic locally (or over a local network).
 
-This is the recommended way for using another reverse-proxy, because the integrated one would act as a black box and wire all Matrix services correctly. You would then only need to reverse-proxy a few individual domains and ports over to it.
+This is the recommended way for using another reverse-proxy, because the integrated one would act as a black box and wire all Matrix services correctly. You would only need to reverse-proxy a few individual domains and ports over to it.
 
 To front Traefik with another reverse-proxy, you would need some configuration like this:
 
@@ -145,64 +131,96 @@ matrix_playbook_reverse_proxy_type: playbook-managed-traefik
 # Ensure that public urls use https
 matrix_playbook_ssl_enabled: true
 
-# Disable the web-secure (port 443) endpoint, which also disables SSL certificate retrieval.
-# This has the side-effect of also automatically disabling TLS for the matrix-federation entrypoint
-# (by toggling `matrix_federation_traefik_entrypoint_tls`).
-traefik_config_entrypoint_web_secure_enabled: false
+# Disable the web-secure (port 443) endpoint, which also disables SSL certificate retrieval
+devture_traefik_config_entrypoint_web_secure_enabled: false
 
 # If your reverse-proxy runs on another machine, consider using `0.0.0.0:81`, just `81` or `SOME_IP_ADDRESS_OF_THIS_MACHINE:81`
-traefik_container_web_host_bind_port: '127.0.0.1:81'
+devture_traefik_container_web_host_bind_port: '127.0.0.1:81'
 
 # We bind to `127.0.0.1` by default (see above), so trusting `X-Forwarded-*` headers from
 # a reverse-proxy running on the local machine is safe enough.
-# If you're publishing the port (`traefik_container_web_host_bind_port` above) to a public network interface:
-# - remove the `traefik_config_entrypoint_web_forwardedHeaders_insecure` variable definition below
-# - uncomment and adjust the `traefik_config_entrypoint_web_forwardedHeaders_trustedIPs` line below
-traefik_config_entrypoint_web_forwardedHeaders_insecure: true
-# traefik_config_entrypoint_web_forwardedHeaders_trustedIPs: ['IP-ADDRESS-OF-YOUR-REVERSE-PROXY']
+devture_traefik_config_entrypoint_web_forwardedHeaders_insecure: true
 
-# Expose the federation entrypoint on a custom port (other than port 8448, which is normally used publicly).
-#
-# We bind to `127.0.0.1` by default (see above), so trusting `X-Forwarded-*` headers from
-# a reverse-proxy running on the local machine is safe enough.
-#
-# If your reverse-proxy runs on another machine, consider:
-# - using `0.0.0.0:8449`, just `8449` or `SOME_IP_ADDRESS_OF_THIS_MACHINE:8449` below
-# - adjusting `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_custom` (below) - removing `insecure: true` and enabling/configuring `trustedIPs`
-matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port: '127.0.0.1:8449'
+# Or, if you're publishing the port (`devture_traefik_container_web_host_bind_port` above) to a public network interfaces:
+# - remove the `devture_traefik_config_entrypoint_web_forwardedHeaders_insecure` variable definition above
+# - uncomment and adjust the line below
+# devture_traefik_config_entrypoint_web_forwardedHeaders_trustedIPs: ['IP-ADDRESS-OF-YOUR-REVERSE-PROXY']
 
-# Disable HTTP/3 for the federation entrypoint.
-# If you'd like HTTP/3, consider configuring it for your other reverse-proxy.
-#
-# Disabling this also sets `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port_udp` to an empty value.
-# If you'd like to keep HTTP/3 enabled here (for whatever reason), you may wish to explicitly
-# set `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port_udp` to something like '127.0.0.1:8449'.
-matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_http3_enabled: false
-
-# Depending on the value of `matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port` above,
-# this may need to be reconfigured. See the comments above.
-matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_custom:
-  forwardedHeaders:
-    insecure: true
-  # trustedIPs: ['IP-ADDRESS-OF-YOUR-REVERSE-PROXY']
+# Likewise (to `devture_traefik_container_web_host_bind_port` above),
+# if your reverse-proxy runs on another machine, consider changing the `host_bind_port` setting below.
+devture_traefik_additional_entrypoints_auto:
+  - name: matrix-federation
+    port: 8449
+    host_bind_port: '127.0.0.1:8449'
+    config: {}
+    # If your reverse-proxy runs on another machine, remove the config above and use this config instead:
+    # config:
+    #   forwardedHeaders:
+    #     insecure: true
+    #     # trustedIPs: ['IP-ADDRESS-OF-YOUR-REVERSE-PROXY']
 ```
 
-Such a configuration would expose all services on a local port `81` and Matrix Federation on a local port `8449`.
-
-Your reverse-proxy configuration needs to send traffic to these ports. The [`examples/reverse-proxies` directory](../examples/reverse-proxies/) contains sample configuration for various webservers (Apache2, Caddy, HAproxy, nginx, Nginx Proxy Manager).
-
-It's important that these webservers proxy-pass requests to the correct place and also set the `Host` HTTP header appropriately.
-If you don't pass the `Host` header correctly, you would get a 404 not found error from Traefik.
-
-To put it another way, `curl http://127.0.0.1:81` would give you a 404, but `curl -H 'Host: matrix.DOMAIN' http://127.0.0.1:81` should work.
+For an example where the playbook's Traefik reverse-proxy is fronted by another reverse-proxy running on the same server, see [Nginx reverse-proxy fronting the playbook's Traefik](../examples/nginx/README.md) or [Caddy reverse-proxy fronting the playbook's Traefik](../examples/caddy2/README.md).
 
 
 ### Using no reverse-proxy on the Matrix side at all
 
-Instead of [Fronting the integrated reverse-proxy webserver with another reverse-proxy](#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy), you can also go another way -- completely disabling the playbook-managed Traefik reverse-proxy. You would then need to reverse-proxy from your own webserver directly to each individual Matrix service.
+Instead of [Fronting the integrated reverse-proxy webserver with another reverse-proxy](#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy), you can also go another way -- completely disabling the playbook-managed reverse-proxy. You would then need to reverse-proxy from your own webserver directly to Matrix services.
 
 This is more difficult, as you would need to handle the configuration for each service manually. Enabling additional services would come with extra manual work you need to do.
 
-Also, the Traefik reverse-proxy, besides fronting everything is also serving a 2nd purpose of allowing addons services to communicate with the Matrix homeserver thanks to its `matrix-internal-matrix-client-api` entrypoint (read more about it above). Disabling Traefik completely means the playbook would wire services to directly talk to the homeserver. This can work for basic setups, but not for more complex setups involving [matrix-media-repo](./configuring-playbook-matrix-media-repo.md), [matrix-corporal](./configuring-playbook-matrix-corporal.md) or other such services that need to "steal routes" from the homeserver.
+If your webserver is on the same machine, sure your web server user (something like `http`, `apache`, `www-data`, `nginx`) is part of the `matrix` group. You should run something like this: `usermod -a -G matrix nginx`. This allows your webserver user to access files owned by the `matrix` group. When using an external nginx webserver, this allows it to read configuration files from `/matrix/nginx-proxy/conf.d`. When using another server, it would make other files, such as `/matrix/static-files/.well-known`, accessible to it.
 
-If your webserver is on the same machine, ensure your web server user (something like `http`, `apache`, `www-data`, `nginx`) is part of the `matrix` group. You should run something like this: `usermod -a -G matrix nginx`. This allows your webserver user to access files owned by the `matrix` group, so that it can serve static files from `/matrix/static-files`.
+#### Using your own nginx reverse-proxy running on the same machine
+
+**WARNING**: this type of setup is not maintained and will be removed in the future. We recommend that you go for [Fronting the integrated reverse-proxy webserver with another reverse-proxy](#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) instead.
+
+If you'll be using `nginx` running on the same machine (not in a container), you can make the playbook help you generate configuration for `nginx` with this configuration:
+
+```yaml
+matrix_playbook_reverse_proxy_type: other-nginx-non-container
+
+# If you want https configured in /matrix/nginx-proxy/conf.d/
+matrix_nginx_proxy_https_enabled: true
+
+# If you will manage SSL certificates yourself, uncomment the line below
+# matrix_ssl_retrieval_method: none
+
+# If you're using an old nginx version, consider using a custom protocol list
+# (removing `TLSv1.3` that is enabled by default) to suit your nginx version.
+# matrix_nginx_proxy_ssl_protocols: "TLSv1.2"
+```
+
+You can most likely directly use the config files installed by this playbook at: `/matrix/nginx-proxy/conf.d`. Just include them in your own `nginx.conf` like this: `include /matrix/nginx-proxy/conf.d/*.conf;`
+
+#### Using your own reverse-proxy running on the same machine or elsewhere
+
+**WARNING**: this is difficult to set up, likely not very well supported and will be removed in the future. We recommend that you go for [Fronting the integrated reverse-proxy webserver with another reverse-proxy](#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) instead.
+
+To reverse-proxy manually for each service, use configuration like this:
+
+```yaml
+# If your reverse-proxy runs on the same machine:
+matrix_playbook_reverse_proxy_type: other-on-same-host
+
+# Or, if it runs on another machine:
+# matrix_playbook_reverse_proxy_type: other-on-another-host
+
+# Or, optionally customize the network interface prefix (note the trailing `:` character).
+# For other-on-same-host, the interface defaults to `127.0.0.1:`.
+# For other-on-another-host, the interface defaults to `0.0.0.0:`.
+# matrix_playbook_service_host_bind_interface_prefix: '192.168.30.4:'
+```
+
+With this configuration, each service will be exposed on a custom port. Example:
+
+- Synapse will be exposed on port `8008`
+- [Grafana](configuring-playbook-prometheus-grafana.md) will be exposed on port `3000`
+- [synapse-admin](configuring-playbook-synapse-admin.md) will be exposed on port `8766`
+
+You can capture traffic for these services and forward it to their port.
+Some of these services are configured with certain default expecations with regard to hostname, path, etc., so it's not completely arbitrary where you can host them (unless you change the defaults).
+
+For each new playbook service that you enable, you'll need special handling.
+
+The [`examples/`](../examples/) directory contains examples for various servers: Caddy, Apache, HAproxy, Nginx, etc.

docs/configuring-playbook-pantalaimon.md

@@ -1,21 +0,0 @@
-# Setting up pantalaimon (optional)
-
-The playbook can install and configure the [pantalaimon](https://github.com/matrix-org/pantalaimon) E2EE aware proxy daemon for you.
-
-See the project's [documentation](https://github.com/matrix-org/pantalaimon) to learn what it does and why it might be useful to you.
-
-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
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
-
-```yaml
-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
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`

docs/configuring-playbook-postgres-backup.md

@@ -1,16 +1,16 @@
 # Setting up postgres backup (optional)
 
-The playbook can install and configure [docker-postgres-backup-local](https://github.com/prodrigestivill/docker-postgres-backup-local) for you via the [ansible-role-postgres-backup](https://github.com/mother-of-all-self-hosting/ansible-role-postgres-backup) Ansible role.
+The playbook can install and configure [docker-postgres-backup-local](https://github.com/prodrigestivill/docker-postgres-backup-local) for you via the [com.devture.ansible.role.postgres_backup](https://github.com/devture/com.devture.ansible.role.postgres_backup) Ansible role.
 
 For a more complete backup solution (one that includes not only Postgres, but also other configuration/data files), you may wish to look into [borg backup](configuring-playbook-backup-borg.md) instead.
 
 
 ## Adjusting the playbook configuration
 
-To enable Postgres backup, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+Minimal working configuration (`inventory/host_vars/matrix.DOMAIN/vars.yml`) to enable Postgres backup:
 
 ```yaml
-postgres_backup_enabled: true
+devture_postgres_backup_enabled: true
 ```
 
 Refer to the table below for additional configuration variables and their default values.
@@ -18,18 +18,18 @@ Refer to the table below for additional configuration variables and their defaul
 
 | Name                              | Default value                | Description                                                      |
 | :-------------------------------- | :--------------------------- | :--------------------------------------------------------------- |
-|`postgres_backup_enabled`|`false`|Set to true to use [docker-postgres-backup-local](https://github.com/prodrigestivill/docker-postgres-backup-local) to create automatic database backups|
-|`postgres_backup_schedule`| `'@daily'` |Cron-schedule specifying the interval between postgres backups.|
-|`postgres_backup_keep_days`|`7`|Number of daily backups to keep|
-|`postgres_backup_keep_weeks`|`4`|Number of weekly backups to keep|
-|`postgres_backup_keep_months`|`12`|Number of monthly backups to keep|
-|`postgres_backup_base_path` | `"{{ matrix_base_data_path }}/postgres-backup"` | Base path for postgres-backup. Also see `postgres_backup_data_path` |
-|`postgres_backup_data_path` | `"{{ postgres_backup_base_path }}/data"` | Storage path for postgres-backup database backups |
+|`devture_postgres_backup_enabled`|`false`|Set to true to use [docker-postgres-backup-local](https://github.com/prodrigestivill/docker-postgres-backup-local) to create automatic database backups|
+|`devture_postgres_backup_schedule`| `'@daily'` |Cron-schedule specifying the interval between postgres backups.|
+|`devture_postgres_backup_keep_days`|`7`|Number of daily backups to keep|
+|`devture_postgres_backup_keep_weeks`|`4`|Number of weekly backups to keep|
+|`devture_postgres_backup_keep_months`|`12`|Number of monthly backups to keep|
+|`devture_postgres_backup_base_path` | `"{{ matrix_base_data_path }}/postgres-backup"` | Base path for postgres-backup. Also see `devture_postgres_backup_data_path` |
+|`devture_postgres_backup_data_path` | `"{{ devture_postgres_backup_base_path }}/data"` | Storage path for postgres-backup database backups |
 
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start

docs/configuring-playbook-prometheus-grafana.md

@@ -22,7 +22,7 @@ grafana_enabled: true
 
 grafana_anonymous_access: false
 
-# This has no relation to your Matrix user ID. It can be any username you'd like.
+# This has no relation to your Matrix user id. It can be any username you'd like.
 # Changing the username subsequently won't work.
 grafana_default_admin_user: "some_username_chosen_by_you"
 
@@ -61,31 +61,43 @@ Most of our docker containers run with limited system access, but the `prometheu
 
 When you'd like **to collect metrics from an external Prometheus server**, you need to expose service metrics outside of the container network.
 
-The playbook provides a single endpoint (`https://matrix.DOMAIN/metrics/*`), under which various services may expose their metrics (e.g. `/metrics/node-exporter`, `/metrics/postgres-exporter`, `/metrics/hookshot`, etc). To expose all services on this `/metrics/*` feature, use `matrix_metrics_exposure_enabled`. To protect access using [Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication), see `matrix_metrics_exposure_http_basic_auth_enabled` and `matrix_metrics_exposure_http_basic_auth_users` below.
-
-When using `matrix_metrics_exposure_enabled`, you don't need to expose metrics for individual services one by one.
+The playbook provides a single endpoint (`https://matrix.DOMAIN/metrics/*`), under which various services may expose their metrics (e.g. `/metrics/node-exporter`, `/metrics/postgres-exporter`, `/metrics/hookshot`, etc). To enable this `/metrics/*` feature, use `matrix_nginx_proxy_proxy_matrix_metrics_enabled`. To protect access using [Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication), see `matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_enabled` below.
 
 The following variables may be of interest:
 
 Name | Description
 -----|----------
-`matrix_metrics_exposure_enabled`|Set this to `true` to **enable metrics exposure for all services** on `https://matrix.DOMAIN/metrics/*`. If you think this is too much, refer to the helpful (but nonexhaustive) list of individual `matrix_SERVICE_metrics_proxying_enabled` (or similar) variables below for exposing metrics on a per-service basis.
-`matrix_metrics_exposure_http_basic_auth_enabled`|Set this to `true` to protect all `https://matrix.DOMAIN/metrics/*` endpoints with [Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) (see the other variables below for supplying the actual credentials). When enabled, all endpoints beneath `/metrics` will be protected with the same credentials
-`matrix_metrics_exposure_http_basic_auth_users`|Set this to the Basic Authentication credentials (raw `htpasswd` file content) used to protect `/metrics/*`. This htpasswd-file needs to be generated with the `htpasswd` tool and can include multiple username/password pairs.
+`matrix_nginx_proxy_proxy_matrix_metrics_enabled`|Set this to `true` to enable metrics exposure for various services on `https://matrix.DOMAIN/metrics/*`. Refer to the individual `matrix_SERVICE_metrics_proxying_enabled` variables below for exposing metrics for each individual service.
+`matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_enabled`|Set this to `true` to protect all `https://matrix.DOMAIN/metrics/*` endpoints with [Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) (see the other variables below for supplying the actual credentials). When enabled, all endpoints beneath `/metrics` will be protected with the same credentials
+`matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_username`|Set this to the Basic Authentication username you'd like to protect `/metrics/*` with. You also need to set `matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_password`. If one username/password pair is not enough, you can leave the `username` and `password` variables unset and use `matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_raw_content` instead
+`matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_password`|Set this to the Basic Authentication password you'd like to protect `/metrics/*` with
+`matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_raw_content`|Set this to the Basic Authentication credentials (raw `htpasswd` file content) used to protect `/metrics/*`. This htpasswd-file needs to be generated with the `htpasswd` tool and can include multiple username/password pairs. If you only need one credential, use `matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_username` and `matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_password` instead.
 `matrix_synapse_metrics_enabled`|Set this to `true` to make Synapse expose metrics (locally, on the container network)
-`matrix_synapse_metrics_proxying_enabled`|Set this to `true` to expose Synapse's metrics on `https://matrix.DOMAIN/metrics/synapse/main-process` and `https://matrix.DOMAIN/metrics/synapse/worker/TYPE-ID`. Read [below](#collecting-synapse-worker-metrics-to-an-external-prometheus-server) if you're running a Synapse worker setup (`matrix_synapse_workers_enabled: true`). To password-protect the metrics, see `matrix_metrics_exposure_http_basic_auth_users` above.
+`matrix_synapse_metrics_proxying_enabled`|Set this to `true` to expose Synapse's metrics on `https://matrix.DOMAIN/metrics/synapse/main-process` and `https://matrix.DOMAIN/metrics/synapse/worker/TYPE-ID` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`). Read [below](#collecting-synapse-worker-metrics-to-an-external-prometheus-server) if you're running a Synapse worker setup (`matrix_synapse_workers_enabled: true`).
 `prometheus_node_exporter_enabled`|Set this to `true` to enable the node (general system stats) exporter (locally, on the container network)
-`prometheus_node_exporter_container_labels_traefik_enabled`|Set this to `true` to expose the node (general system stats) metrics on `https://matrix.DOMAIN/metrics/node-exporter`. To password-protect the metrics, see `matrix_metrics_exposure_http_basic_auth_users` above.
+`matrix_prometheus_services_proxy_connect_prometheus_node_exporter_metrics_proxying_enabled`|Set this to `true` to expose the node (general system stats) metrics on `https://matrix.DOMAIN/metrics/node-exporter` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
 `prometheus_postgres_exporter_enabled`|Set this to `true` to enable the [Postgres exporter](configuring-playbook-prometheus-postgres.md) (locally, on the container network)
-`prometheus_postgres_exporter_container_labels_traefik_enabled`|Set this to `true` to expose the [Postgres exporter](configuring-playbook-prometheus-postgres.md) metrics on `https://matrix.DOMAIN/metrics/postgres-exporter`. To password-protect the metrics, see `matrix_metrics_exposure_http_basic_auth_users` above.
 `matrix_prometheus_nginxlog_exporter_enabled`|Set this to `true` to enable the [NGINX Log exporter](configuring-playbook-prometheus-nginxlog.md) (locally, on the container network)
-`matrix_sliding_sync_metrics_enabled`|Set this to `true` to make [Sliding Sync](configuring-playbook-sliding-sync-proxy.md) expose metrics (locally, on the container network)
-`matrix_sliding_sync_metrics_proxying_enabled`|Set this to `true` to expose the [Sliding Sync](configuring-playbook-sliding-sync-proxy.md) metrics on `https://matrix.DOMAIN/metrics/sliding-sync`. To password-protect the metrics, see `matrix_metrics_exposure_http_basic_auth_users` above.
+`matrix_prometheus_services_proxy_connect_prometheus_postgres_exporter_metrics_proxying_enabled`|Set this to `true` to expose the [Postgres exporter](configuring-playbook-prometheus-postgres.md) metrics on `https://matrix.DOMAIN/metrics/postgres-exporter` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
 `matrix_bridge_hookshot_metrics_enabled`|Set this to `true` to make [Hookshot](configuring-playbook-bridge-hookshot.md) expose metrics (locally, on the container network)
-`matrix_bridge_hookshot_metrics_proxying_enabled`|Set this to `true` to expose the [Hookshot](configuring-playbook-bridge-hookshot.md) metrics on `https://matrix.DOMAIN/metrics/hookshot`. To password-protect the metrics, see `matrix_metrics_exposure_http_basic_auth_users` above.
-`matrix_SERVICE_metrics_proxying_enabled`|Various other services/roles may provide similar `_metrics_enabled` and `_metrics_proxying_enabled` variables for exposing their metrics. Refer to each role for details. To password-protect the metrics, see `matrix_metrics_exposure_http_basic_auth_users` above or `matrix_SERVICE_container_labels_metrics_middleware_basic_auth_enabled`/`matrix_SERVICE_container_labels_metrics_middleware_basic_auth_users` variables provided by each role.
+`matrix_bridge_hookshot_metrics_proxying_enabled`|Set this to `true` to expose the [Hookshot](configuring-playbook-bridge-hookshot.md) metrics on `https://matrix.DOMAIN/metrics/hookshot` (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
+`matrix_SERVICE_metrics_proxying_enabled`|Various other services/roles may provide similar `_metrics_enabled` and `_metrics_proxying_enabled` variables for exposing their metrics. Refer to each role for details. Only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`
+`matrix_nginx_proxy_proxy_matrix_metrics_additional_user_location_configuration_blocks`|Add nginx `location` blocks to this list if you'd like to expose additional exporters manually (see below)
 `matrix_media_repo_metrics_enabled`|Set this to `true` to make media-repo expose metrics (locally, on the container network)
 
+Example for how to make use of `matrix_nginx_proxy_proxy_matrix_metrics_additional_user_location_configuration_blocks` for exposing additional metrics locations:
+```nginx
+matrix_nginx_proxy_proxy_matrix_metrics_additional_user_location_configuration_blocks:
+  - 'location /metrics/another-service {
+  resolver 127.0.0.11 valid=5s;
+  proxy_pass http://matrix-another-service:9100/metrics;
+  }'
+```
+
+Using `matrix_nginx_proxy_proxy_matrix_metrics_additional_user_location_configuration_blocks` only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true` (see above).
+
+Note : The playbook will hash the basic_auth password for you on setup. Thus, you need to give the plain-text version of the password as a variable.
+
 ### Collecting Synapse worker metrics to an external Prometheus server
 
 If you are using workers (`matrix_synapse_workers_enabled: true`) and have enabled `matrix_synapse_metrics_proxying_enabled` as described above, the playbook will also automatically expose all Synapse worker threads' metrics to `https://matrix.DOMAIN/metrics/synapse/worker/ID`, where `ID` corresponds to the worker `id` as exemplified in `matrix_synapse_workers_enabled_list`.
@@ -121,8 +133,7 @@ scrape_configs:
 
 ## More information
 
-- [Enabling synapse-usage-exporter for Synapse usage statistics](configuring-playbook-synapse-usage-exporter.md)
-- [Understanding Synapse Performance Issues Through Grafana Graphs](https://element-hq.github.io/synapse/latest/usage/administration/understanding_synapse_through_grafana_graphs.html) at the Synapse Github Wiki
-- [The Prometheus scraping rules](https://github.com/element-hq/synapse/tree/master/contrib/prometheus) (we use v2)
-- [The Synapse Grafana dashboard](https://github.com/element-hq/synapse/tree/master/contrib/grafana)
+- [Understanding Synapse Performance Issues Through Grafana Graphs](https://github.com/matrix-org/synapse/wiki/Understanding-Synapse-Performance-Issues-Through-Grafana-Graphs) at the Synapse Github Wiki
+- [The Prometheus scraping rules](https://github.com/matrix-org/synapse/tree/master/contrib/prometheus) (we use v2)
+- [The Synapse Grafana dashboard](https://github.com/matrix-org/synapse/tree/master/contrib/grafana)
 - [The Node Exporter dashboard](https://github.com/rfrail3/grafana-dashboards) (for generic non-synapse performance graphs)

docs/configuring-playbook-prometheus-nginxlog.md

@@ -1,36 +1,34 @@
 # Enabling metrics and graphs for NginX logs (optional)
 
-It can be useful to have some (visual) insight into [nginx](https://nginx.org/) logs.
+It can be useful to have some (visual) insight into NignX logs.
 
-This adds [prometheus-nginxlog-exporter](https://github.com/martin-helmich/prometheus-nginxlog-exporter/) to your Matrix deployment.
+This adds [prometheus-nginxlog-exporter](https://github.com/martin-helmich/prometheus-nginxlog-exporter/) to your matrix deployment.
+It will provide a prometheus 'metrics' endpoint exposing data from both the `matrix-nginx-proxy` and `matrix-synapse-reverse-proxy-companion` logs and automatically aggregates the data with prometheus.
+Optionally it visualizes the data, if [`matrix-grafana`](configuring-playbook-prometheus-grafana.md) is enabled, by means of a dedicated Grafana dashboard named `NGINX PROXY`
 
-It will collect access logs from various nginx reverse-proxies which may be used internally (e.g. `matrix-synapse-reverse-proxy-companion`, if Synapse workers are enabled) and will make them available at a Prometheus-compatible `/metrics` endpoint.
-
-**Note**: nginx is only used internally by this Ansible playbook. With Traefik being our default reverse-proxy, collecting nginx metrics is less relevant.
-
-To make use of this, you need to install [Prometheus](./configuring-playbook-prometheus-grafana.md) either via the playbook or externally. When using an external Prometheus, configuration adjustments are necessary - see [Save metrics on an external Prometheus server](#save-metrics-on-an-external-prometheus-server).
-
-If your setup includes [Grafana](./configuring-playbook-prometheus-grafana.md), a dedicated `NGINX PROXY` Grafana dashboard will be created.
-
-## Configuration
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+You can enable this role by adding the following settings in your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
 
 ```yaml
 matrix_prometheus_nginxlog_exporter_enabled: true
+
+# required depency
+prometheus_enabled: true
+
+# optional for visualization
+grafana_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
+x | Prerequisites | Variable | Description
+|:--:|:--:|:--:|:--|
+**REQUIRED** | `matrix-prometheus`| `prometheus_enabled`|[Prometheus](https://prometheus.io) is a time series database. It holds all the data we're going to talk about.
+_Optional_ | [`matrix-grafana`](configuring-playbook-prometheus-grafana.md) | [`grafana_enabled`](configuring-playbook-prometheus-grafana.md)|[Grafana](https://grafana.com) is the visual component. It shows (on the `stats.<your-domain>` subdomain) graphs that we're interested in. When enabled the `NGINX PROXY` dashboard is automatically added.
 
 ## Docker Image Compatibility
 
 At the moment of writing only images for `amd64` and `arm64` architectures are available
 
-The playbook currently does not support [self-building](./self-building.md) a container image on other architectures.
-You can however use a custom-build image by setting:
-
+The playbook currently does not support building an image.
+You can however use a custom-build image by setting
 ```yaml
 matrix_prometheus_nginxlog_exporter_docker_image_arch_check_enabled: false
 matrix_prometheus_nginxlog_exporter_docker_image: path/to/docker/image:tag
@@ -43,12 +41,19 @@ Please make sure you change the default Grafana password.
 
 ## Save metrics on an external Prometheus server
 
-The playbook will automatically integrate the metrics into the [Prometheus](./configuring-playbook-prometheus-grafana.md) server provided with this playbook (if enabled). In such cases, the metrics endpoint is not exposed publicly - it's only available on the container network.
+The playbook will automatically integrate the metrics into the Prometheus server provided with this playbook. You can choose to save data on an external Prometheus instance.
 
-When using an external Prometheus server, you'll need to expose metrics publicly. See [Collecting metrics to an external Prometheus server](./configuring-playbook-prometheus-grafana.md#collecting-metrics-to-an-external-prometheus-server).
+The metrics of this role will be exposed on `https://matrix.DOMAIN/metrics/nginxlog` when setting
+```yaml
+matrix_prometheus_nginxlog_exporter_metrics_proxying_enabled: true
 
-You can either use `matrix_prometheus_nginxlog_exporter_metrics_proxying_enabled: true` to expose just this one service, or `matrix_metrics_exposure_enabled: true` to expose all services.
+# required dependency
+matrix_nginx_proxy_proxy_matrix_metrics_enabled: true
+```
+The playbook can provide a single endpoint (`https://matrix.DOMAIN/metrics/*`), under which various services may expose their metrics (e.g. `/metrics/node-exporter`, `/metrics/postgres-exporter`, `/metrics/nginxlog`, etc). To enable this `/metrics/*` feature, use `matrix_nginx_proxy_proxy_matrix_metrics_enabled`. To protect access using [Basic Authentication](https://en.wikipedia.org/wiki/Basic_access_authentication), see `matrix_nginx_proxy_proxy_matrix_metrics_basic_auth_enabled`.
 
-Whichever way you go with, this service will expose its metrics endpoint **without password-protection** at `https://matrix.DOMAIN/metrics/nginxlog` by default.
+The following variables may be of interest:
 
-For password-protection, use (`matrix_metrics_exposure_http_basic_auth_enabled` and `matrix_metrics_exposure_http_basic_auth_users`) or (`matrix_prometheus_nginxlog_exporter_container_labels_metrics_middleware_basic_auth_enabled` and `matrix_prometheus_nginxlog_exporter_container_labels_metrics_middleware_basic_auth_users`).
+Name | Description
+-----|----------
+`matrix_nginx_proxy_proxy_matrix_metrics_enabled`|Set this to `true` to enable metrics exposure for various services on `https://matrix.DOMAIN/metrics/*`. Refer to the individual `matrix_SERVICE_metrics_proxying_enabled` variables below for exposing metrics for each individual service.

docs/configuring-playbook-prometheus-postgres.md

@@ -2,18 +2,13 @@
 
 Expanding on the metrics exposed by the [synapse exporter and the node exporter](configuring-playbook-prometheus-grafana.md), the playbook enables the [postgres exporter](https://github.com/prometheus-community/postgres_exporter) that exposes more detailed information about what's happening on your postgres database.
 
-## Adjusting the playbook configuration
+You can enable this with the following settings in your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
 
-To enable the postgres exporter, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 
 ```yaml
 prometheus_postgres_exporter_enabled: true
 ```
 
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
-
 ## What does it do?
 
 Name | Description
@@ -21,9 +16,10 @@ Name | Description
 `prometheus_postgres_exporter_enabled`|Enable the postgres prometheus exporter. This sets up the docker container, connects it to the database and adds a 'job' to the prometheus config which tells prometheus about this new exporter. The default is 'false'
 `prometheus_postgres_exporter_database_username`| The 'username' for the user that the exporter uses to connect to the database. The default is 'matrix_prometheus_postgres_exporter'
 `prometheus_postgres_exporter_database_password`| The 'password' for the user that the exporter uses to connect to the database. By default, this is auto-generated by the playbook
-`prometheus_postgres_exporter_container_labels_traefik_enabled`|If set to `true`, exposes the Postgres exporter metrics on `https://matrix.DOMAIN/metrics/postgres-exporter` for usage with an [external Prometheus server](configuring-playbook-prometheus-grafana.md#collecting-metrics-to-an-external-prometheus-server). To password-protect the metrics, see `matrix_metrics_exposure_http_basic_auth_users` on that other documentation page.
+`matrix_prometheus_services_proxy_connect_prometheus_postgres_exporter_metrics_proxying_enabled`|If set to `true`, exposes the Postgres exporter metrics on `https://matrix.DOMAIN/metrics/postgres-exporter` for usage with an [external Prometheus server](configuring-playbook-prometheus-grafana.md#collecting-metrics-to-an-external-prometheus-server) (only takes effect if `matrix_nginx_proxy_proxy_matrix_metrics_enabled: true`)
 
 
 ## More information
 
 - [The PostgresSQL dashboard](https://grafana.com/grafana/dashboards/9628) (generic postgres dashboard)
+

docs/configuring-playbook-rageshake.md

@@ -20,6 +20,8 @@ matrix_rageshake_hostname: "{{ matrix_server_fqn_matrix }}"
 matrix_rageshake_path_prefix: /rageshake
 ```
 
+**NOTE**: When using `matrix-nginx-proxy` instead of Traefik, you won't be able to override the path prefix. You can only override the domain, but that needs to happen using another variable: `matrix_server_fqn_rageshake` (e.g. `matrix_server_fqn_rageshake: "some-domain.{{ matrix_domain }}"`).
+
 
 ## Adjusting DNS records
 
@@ -51,7 +53,7 @@ matrix_rageshake_configuration_extension_yaml: |
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start

docs/configuring-playbook-rest-auth.md

@@ -4,9 +4,7 @@ The playbook can install and configure [matrix-synapse-rest-auth](https://github
 
 See that project's documentation to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
+If you decide that you'd like to let this playbook install it for you, you need some configuration like this:
 
 ```yaml
 matrix_synapse_ext_password_provider_rest_auth_enabled: true
@@ -16,6 +14,7 @@ matrix_synapse_ext_password_provider_rest_auth_registration_profile_name_autofil
 matrix_synapse_ext_password_provider_rest_auth_login_profile_name_autofill: false
 ```
 
+
 ## Authenticating only using a password provider
 
 If you wish for users to **authenticate only against configured password providers** (like this one), **without consulting Synapse's local database**, feel free to disable it:
@@ -23,7 +22,3 @@ If you wish for users to **authenticate only against configured password provide
 ```yaml
 matrix_synapse_password_config_localdb_enabled: false
 ```
-
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`

docs/configuring-playbook-riot-web.md

@@ -1,6 +1,6 @@
 # Configuring Riot-web (optional)
 
-By default, this playbook **used to install** the [Riot-web](https://github.com/element-hq/riot-web) Matrix client web application.
+By default, this playbook **used to install** the [Riot-web](https://github.com/vector-im/riot-web) Matrix client web application.
 
 Riot has since been [renamed to Element](https://element.io/blog/welcome-to-element/).
 
@@ -25,9 +25,15 @@ There are a few options for handling this:
 
 - (**avoiding changes** - using the old `riot.DOMAIN` domain and avoiding DNS changes) -- to keep using `riot.DOMAIN` instead of `element.DOMAIN`, override the domain at which the playbook serves Element: `matrix_server_fqn_element: "riot.{{ matrix_domain }}"`
 
-- (**embracing changes** - using only `element.DOMAIN`) - set up the `element.DOMAIN` DNS record (see [Configuring DNS](configuring-dns.md)). You can drop the `riot.DOMAIN` in this case.
+- (**embracing changes** - using only `element.DOMAIN`) - set up the `element.DOMAIN` DNS record (see [Configuring DNS](configuring-dns.md)). You can drop the `riot.DOMAIN` in this case. If so, you may also wish to remove old SSL certificates (`rm -rf /matrix/ssl/config/live/riot.DOMAIN`) and renewal configuration (`rm -f /matrix/ssl/config/renewal/riot.DOMAIN.conf`), so that `certbot` would stop trying to renew them.
+
+- (**embracing changes and transitioning smoothly** - using both `element.DOMAIN` and `riot.DOMAIN`) - to serve Element at the new domain (`element.DOMAIN`) and to also have `riot.DOMAIN` redirect there - set up the `element.DOMAIN` DNS record (see [Configuring DNS](configuring-dns.md)) and enable Riot to Element redirection (`matrix_nginx_proxy_proxy_riot_compat_redirect_enabled: true`).
 
 
 ### Re-running the playbook
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`
+As always, after making the necessary DNS and configuration adjustments, re-run the playbook to apply the changes:
+
+```
+ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
+```

docs/configuring-playbook-s3-goofys.md

@@ -9,9 +9,10 @@ Using a Goofys-backed media store works, but performance may not be ideal. If po
 
 If you'd like to move your locally-stored media store data to Amazon S3 (or another S3-compatible object store), we also provide some migration instructions below.
 
-## Adjusting the playbook configuration
 
-After [creating the S3 bucket and configuring it](configuring-playbook-s3.md#bucket-creation-and-security-configuration), add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
+## Usage
+
+After [creating the S3 bucket and configuring it](configuring-playbook-s3.md#bucket-creation-and-security-configuration), you can proceed to configure Goofys in your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
 
 ```yaml
 matrix_s3_media_store_enabled: true

docs/configuring-playbook-s3.md

@@ -65,7 +65,7 @@ You'll need an Amazon S3 bucket and some IAM user credentials (access key + secr
 }
 ```
 
-**Note**: This policy needs to be attached to an IAM user created from the **Security Credentials** menu. This is not a **Bucket Policy**.
+**NOTE**: This policy needs to be attached to an IAM user created from the **Security Credentials** menu. This is not a **Bucket Policy**.
 
 
 ## Backblaze B2

docs/configuring-playbook-shared-secret-auth.md

@@ -4,17 +4,16 @@ The playbook can install and configure [matrix-synapse-shared-secret-auth](https
 
 See that project's documentation to learn what it does and why it might be useful to you.
 
-## Adjusting the playbook configuration
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+If you decide that you'd like to let this playbook install it for you, you need some configuration (`inventory/host_vars/matrix.<your-domain>/vars.yml`) like this:
 
 ```yaml
 matrix_synapse_ext_password_provider_shared_secret_auth_enabled: true
-
-# Generate a strong shared secret here. Consider generating it with `pwgen -s 64 1`
 matrix_synapse_ext_password_provider_shared_secret_auth_shared_secret: YOUR_SHARED_SECRET_GOES_HERE
 ```
 
+You can generate a strong shared secret with a command like this: `pwgen -s 64 1`
+
+
 ## Authenticating only using a password provider
 
 If you wish for users to **authenticate only against configured password providers** (like this one), **without consulting Synapse's local database**, feel free to disable it:
@@ -22,7 +21,3 @@ If you wish for users to **authenticate only against configured password provide
 ```yaml
 matrix_synapse_password_config_localdb_enabled: false
 ```
-
-## Installing
-
-After configuring the playbook, run the [installation](installing.md) command: `just install-all` or `just setup-all`

docs/configuring-playbook-sliding-sync-proxy.md

@@ -2,15 +2,17 @@
 
 The playbook can install and configure [sliding-sync](https://github.com/matrix-org/sliding-sync) proxy for you.
 
-Sliding Sync is an implementation of [MSC3575](https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/sync-v3/proposals/3575-sync.md) and a prerequisite for running the new (**still beta**) Element X clients ([Element X iOS](https://github.com/element-hq/element-x-ios) and [Element X Android](https://github.com/element-hq/element-x-android)).
+Sliding Sync is an implementation of [MSC3575](https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/sync-v3/proposals/3575-sync.md) and a prerequisite for running the new (**still beta**) Element X clients ([Element X iOS](https://github.com/vector-im/element-x-ios) and [Element X Android](https://github.com/vector-im/element-x-android)).
 
 See the project's [documentation](https://github.com/matrix-org/sliding-sync) to learn more.
 
 Element X iOS is [available on TestFlight](https://testflight.apple.com/join/uZbeZCOi).
 
-Element X Android is [available on the Github Releases page](https://github.com/element-hq/element-x-android/releases).
+Element X Android is [available on the Github Releases page](https://github.com/vector-im/element-x-android/releases).
 
-**Note**: The sliding-sync proxy is **not required** when using the **Conduit homeserver**. Starting from version `0.6.0` Conduit has native support for some sliding sync features. If there are issues with the native implementation, you might have a better experience when enabling the sliding-sync proxy anyway.
+**NOTE**: The Sliding Sync proxy **only works with the Traefik reverse-proxy**. If you have an old server installation (from the time `matrix-nginx-proxy` was our default reverse-proxy - `matrix_playbook_reverse_proxy_type: playbook-managed-nginx`), you won't be able to use Sliding Sync.
+
+**NOTE**: The sliding-sync proxy is **not required** when using the **Conduit homeserver**. Starting from version `0.6.0` Conduit has native support for some sliding sync features. If there are issues with the native implementation, you might have a better experience when enabling the sliding-sync proxy anyway.
 
 ## Decide on a domain and path
 
@@ -23,7 +25,7 @@ If you'd like to run the Sliding Sync proxy on another hostname or path, use the
 
 ## Adjusting DNS records
 
-If you've changed the default hostname, **you may need to adjust your DNS** records.
+If you've changed the default hostame, **you may need to adjust your DNS** records.
 
 
 ## Adjusting the playbook configuration

docs/configuring-playbook-ssl-certificates.md

@@ -9,10 +9,10 @@ This guide is about using the integrated Traefik server and doesn't apply if you
 
 For testing purposes, you may wish to use staging certificates provide by Let's Encrypt.
 
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+You can do this with the following configuration:
 
 ```yaml
-traefik_config_certificatesResolvers_acme_use_staging: true
+devture_traefik_config_certificatesResolvers_acme_use_staging: true
 ```
 
 
@@ -20,10 +20,10 @@ traefik_config_certificatesResolvers_acme_use_staging: true
 
 For testing or other purposes, you may wish to install services without SSL termination and have services exposed to `http://` instead of `https://`.
 
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
+You can do this with the following configuration:
 
 ```yaml
-traefik_config_entrypoint_web_secure_enabled: false
+devture_traefik_config_entrypoint_web_secure_enabled: false
 ```
 
 
@@ -46,16 +46,16 @@ To use your own SSL certificates with Traefik, you need to:
 
 ```yaml
 # Disable ACME / Let's Encrypt support.
-traefik_config_certificatesResolvers_acme_enabled: false
+devture_traefik_config_certificatesResolvers_acme_enabled: false
 
 # Disabling ACME support (above) automatically disables the creation of the SSL directory.
 # Force-enable it here, because we'll add our certificate files there.
-traefik_ssl_dir_enabled: true
+devture_traefik_ssl_dir_enabled: true
 
 # Tell Traefik to load our custom configuration file (certificates.yml).
 # The file is created below, in `aux_file_definitions`.
 # The `/config/..` path is an in-container path, not a path on the host (like `/matrix/traefik/config`). Do not change it!
-traefik_configuration_extension_yaml: |
+devture_traefik_configuration_extension_yaml: |
   providers:
     file:
       filename: /config/certificates.yml
@@ -66,7 +66,7 @@ traefik_configuration_extension_yaml: |
 aux_file_definitions:
   # Create the privkey.pem file on the server by
   # uploading a file from the computer where Ansible is running.
-  - dest: "{{ traefik_ssl_dir_path }}/privkey.pem"
+  - dest: "{{ devture_traefik_ssl_dir_path }}/privkey.pem"
     src: /path/on/your/Ansible/computer/to/privkey.pem
     # Alternatively, comment out `src` above and uncomment the lines below to provide the certificate content inline.
     # Note the indentation level.
@@ -76,7 +76,7 @@ aux_file_definitions:
 
   # Create the cert.pem file on the server
   # uploading a file from the computer where Ansible is running.
-  - dest: "{{ traefik_ssl_dir_path }}/cert.pem"
+  - dest: "{{ devture_traefik_ssl_dir_path }}/cert.pem"
     src: /path/on/your/Ansible/computer/to/cert.pem
     # Alternatively, comment out `src` above and uncomment the lines below to provide the certificate content inline.
     # Note the indentation level.
@@ -86,7 +86,7 @@ aux_file_definitions:
 
   # Create the custom Traefik configuration.
   # The `/ssl/..` paths below are in-container paths, not paths on the host (/`matrix/traefik/ssl/..`). Do not change them!
-  - dest: "{{ traefik_config_dir_path }}/certificates.yml"
+  - dest: "{{ devture_traefik_config_dir_path }}/certificates.yml"
     content: |
       tls:
         certificates:
@@ -98,29 +98,3 @@ aux_file_definitions:
               certFile: /ssl/cert.pem
               keyFile: /ssl/privkey.pem
 ```
-
-## Using a DNS-01 ACME challenge type, instead of HTTP-01
-
-You can configure Traefik to use the [DNS-01 challenge type](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) for Let's Encrypt. This is less commonly used than the default [HTTP-01 challenge type](https://letsencrypt.org/docs/challenge-types/#http-01-challenge), but it can be helpful to:
-
-- hide your public IP from Let's Encrypt logs
-- allow you to obtain SSL certificates for servers which are not accessible (via HTTP) from the public internet (and for which the HTTP-01 challenge would fail)
-
-This is an example for how to edit the `vars.yml` file if you're using Cloudflare:
-
-```yaml
-traefik_config_certificatesResolvers_acme_dnsChallenge_enabled: true
-traefik_config_certificatesResolvers_acme_dnsChallenge_provider: "cloudflare"
-traefik_config_certificatesResolvers_acme_dnsChallenge_delayBeforeCheck: 60
-traefik_config_certificatesResolvers_acme_dnsChallenge_resolvers:
-  - "1.1.1.1:53"
-traefik_environment_variables_additional_variables: |
-  CF_API_EMAIL=redacted
-  CF_ZONE_API_TOKEN=redacted
-  CF_DNS_API_TOKEN=redacted
-  LEGO_DISABLE_CNAME_SUPPORT=true
-```
-
-Make sure to change the value of "provider" to your particular DNS solution, and provide the appropriate environment variables. The full list of supported providers is available [here](https://doc.traefik.io/traefik/https/acme/#providers).
-
-This example assumes you're using Cloudflare to manage your DNS zone. Note that it requires the use of two tokens: one for reading all zones (`CF_ZONE_API_TOKEN`) and another that must be able to edit the particular domain you're using (`CF_DNS_API_TOKEN`). For security, it's recommended that you create two fine-grained tokens for this purpose, but you might choose to use the same token for both.

docs/configuring-playbook-sygnal.md

@@ -26,6 +26,8 @@ matrix_sygnal_hostname: "{{ matrix_server_fqn_matrix }}"
 matrix_sygnal_path_prefix: /sygnal
 ```
 
+**NOTE**: When using `matrix-nginx-proxy` instead of Traefik, you won't be able to override the path prefix. You can only override the domain, but that needs to happen using another variable: `matrix_server_fqn_sygnal` (e.g. `matrix_server_fqn_sygnal: "push.{{ matrix_domain }}"`).
+
 
 ## Adjusting DNS records
 

docs/configuring-playbook-synapse-admin.md

@@ -1,10 +1,10 @@
 # Setting up Synapse Admin (optional)
 
-The playbook can install and configure [etkecc/synapse-admin](https://github.com/etkecc/synapse-admin) (a [feature-rich](https://github.com/etkecc/synapse-admin#fork-differences) fork of [Awesome-Technologies/synapse-admin](https://github.com/Awesome-Technologies/synapse-admin)) for you.
+The playbook can install and configure [synapse-admin](https://github.com/Awesome-Technologies/synapse-admin) for you.
 
-synapse-admin is a web UI tool you can use to **administrate users, rooms, media, etc. on your Matrix server**. It's designed to work with the Synapse homeserver implementation, but to some extent may work with [Dendrite](./configuring-playbook-dendrite.md) as well.
+It's a web UI tool you can use to **administrate users and rooms on your Matrix server**.
 
-See the project's [documentation](https://github.com/etkecc/synapse-admin) to learn what it does and why it might be useful to you.
+See the project's [documentation](https://github.com/Awesome-Technologies/synapse-admin) to learn what it does and why it might be useful to you.
 
 
 ## Adjusting the playbook configuration
@@ -15,17 +15,16 @@ Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.
 matrix_synapse_admin_enabled: true
 ```
 
-**Note**: Synapse Admin requires Synapse's [Admin APIs](https://element-hq.github.io/synapse/latest/usage/administration/admin_api/index.html) to function. Access to them is restricted with a valid access token, so exposing them publicly should not be a real security concern. Still, for additional security, we normally leave them unexposed, following [official Synapse reverse-proxying recommendations](https://element-hq.github.io/synapse/latest/reverse_proxy.html#synapse-administration-endpoints). Because Synapse Admin needs these APIs to function, when installing Synapse Admin, the playbook **automatically** exposes the Synapse Admin API publicly for you. Depending on the homeserver implementation you're using (Synapse, Dendrite), this is equivalent to:
-
-- for [Synapse](./configuring-playbook-synapse.md) (our default homeserver implementation): `matrix_synapse_container_labels_public_client_synapse_admin_api_enabled: true`
-- for [Dendrite](./configuring-playbook-dendrite.md): `matrix_dendrite_container_labels_public_client_synapse_admin_api_enabled: true`
-
-By default, synapse-admin installation will be [restricted to only work with one homeserver](https://github.com/etkecc/synapse-admin/blob/e21e44362c879ac41f47c580b04210842b6ff3d7/README.md#restricting-available-homeserver) - the one managed by the playbook. To adjust these restrictions, tweak the `matrix_synapse_admin_config_restrictBaseUrl` variable.
+**Note**: Synapse Admin requires Synapse's [Admin APIs](https://matrix-org.github.io/synapse/latest/usage/administration/admin_api/index.html) to function. Access to them is restricted with a valid access token, so exposing them publicly should not be a real security concern. Still, for additional security, we normally leave them unexposed, following [official Synapse reverse-proxying recommendations](https://github.com/matrix-org/synapse/blob/master/docs/reverse_proxy.md#synapse-administration-endpoints). Because Synapse Admin needs these APIs to function, when installing Synapse Admin, we **automatically** exposes them publicly for you (equivalent to `matrix_nginx_proxy_proxy_matrix_client_api_forwarded_location_synapse_admin_api_enabled: true`).
 
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command: `just install-all`
+After configuring the playbook, run the [installation](installing.md) command again:
+
+```
+ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
+```
 
 
 ## Usage
@@ -33,3 +32,17 @@ After configuring the playbook, run the [installation](installing.md) command: `
 After installation, Synapse Admin will be accessible at: `https://matrix.DOMAIN/synapse-admin/`
 
 To use Synapse Admin, you need to have [registered at least one administrator account](registering-users.md) on your server.
+
+The Homeserver URL to use on Synapse Admin's login page is: `https://matrix.DOMAIN`
+
+### Sample configuration for running behind Caddy v2
+
+Below is a sample configuration for using this playbook with a [Caddy](https://caddyserver.com/v2) 2.0 reverse proxy (non-default configuration where `matrix-nginx-proxy` is disabled - `matrix_nginx_proxy_enabled: false`).
+
+```caddy
+# This is a basic configuration that will function the same as the default nginx proxy - exposing the synapse-admin panel to matrix.YOURSERVER.com/synapse-admin/
+  handle_path /synapse-admin* {
+        reverse_proxy localhost:8766  {
+        }
+  }
+```

docs/configuring-playbook-synapse-auto-accept-invite.md

@@ -1,47 +0,0 @@
-# Setting up Synapse Auto Invite Accept (optional)
-
-The playbook can install and configure [synapse-auto-invite-accept](https://github.com/matrix-org/synapse-auto-accept-invite) for you.
-
-See that project's [documentation](https://github.com/matrix-org/synapse-auto-accept-invite) to learn what it does and why it might be useful to you.
-In short, it automatically accepts room invites. You can specify that only 1:1 room invites are auto-accepted. Defaults to false if not specified.
-
-**Note**: Synapse [v1.109.0](https://github.com/element-hq/synapse/releases/tag/v1.109.0), the same feature [has been merged](https://github.com/element-hq/synapse/pull/17147) into Synapse (see the [Native alternative](#native-alternative) section below). You'd better use the native feature, instead of the [synapse-auto-invite-accept](https://github.com/matrix-org/synapse-auto-accept-invite) 3rd party module.
-
-
-## Configuration
-
-If you decide that you'd like to let this playbook install the [synapse-auto-invite-accept](https://github.com/matrix-org/synapse-auto-accept-invite module for you, add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
-
-```yaml
-matrix_synapse_ext_synapse_auto_accept_invite_enabled: true
-
-matrix_synapse_ext_synapse_auto_accept_invite_accept_invites_only_direct_messages: true
-```
-
-### Synapse worker deployments
-
-In a [workerized Synapse deployment](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/c9a842147e09647c355799ca024d65a5de66b099/docs/configuring-playbook-synapse.md#load-balancing-with-workers) it is possible to run this module on a worker to reduce the load on the main process (Default is `null`). For example, add this to your configuration:
-
-```yaml
-matrix_synapse_ext_synapse_auto_accept_invite_worker_to_run_on: 'matrix-synapse-worker-generic-0'
-```
-
-There might be an [issue with federation](https://github.com/matrix-org/synapse-auto-accept-invite/issues/18).
-
-
-## Native alternative
-
-Since Synapse [v1.109.0](https://github.com/element-hq/synapse/releases/tag/v1.109.0), the functionality provided by the [synapse-auto-invite-accept](https://github.com/matrix-org/synapse-auto-accept-invite) 3rd party module [has been made](https://github.com/element-hq/synapse/pull/17147) part of Synapse.
-
-Here's example configuration for using the **native** Synapse feature:
-
-```yml
-matrix_synapse_auto_accept_invites_enabled: true
-
-# Default settings below. Uncomment and adjust this part if necessary.
-# matrix_synapse_auto_accept_invites_only_for_direct_messages: false
-# matrix_synapse_auto_accept_invites_only_from_local_users: false
-
-# If workers are enabled, you may delegate usage to a specific worker.
-# matrix_synapse_auto_accept_invites_worker_to_run_on: 'matrix-synapse-worker-generic-0'
-```

docs/configuring-playbook-synapse-auto-compressor.md

@@ -18,7 +18,7 @@ matrix_synapse_auto_compressor_enabled: true
 
 ## Installing
 
-After configuring the playbook, run the [installation](installing.md) command:
+After configuring the playbook, run the [installation](installing.md) command again:
 
 ```
 ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start

docs/configuring-playbook-synapse-s3-storage-provider.md

@@ -36,7 +36,7 @@ matrix_synapse_ext_synapse_s3_storage_provider_config_region_name: some-region-n
 matrix_synapse_ext_synapse_s3_storage_provider_config_endpoint_url: https://s3.REGION_NAME.amazonaws.com # adjust this
 matrix_synapse_ext_synapse_s3_storage_provider_config_storage_class: STANDARD # or STANDARD_IA, etc.
 
-# Authentication Method 1 - (access key ID + secret)
+# Authentication Method 1 - (access key id + secret)
 # This works on all providers (AWS and other compatible systems).
 # Uncomment the variables below to use it.
 # matrix_synapse_ext_synapse_s3_storage_provider_config_access_key_id: access-key-goes-here

docs/configuring-playbook-synapse-simple-antispam.md

@@ -5,9 +5,7 @@ The playbook can install and configure [synapse-simple-antispam](https://github.
 See that project's documentation to learn what it does and why it might be useful to you.
 In short, it lets you fight invite-spam by automatically blocking invitiations from a list of servers specified by you (blacklisting).
 
-## Adjusting the playbook configuration
-
-Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
+If you decide that you'd like to let this playbook install it for you, you need some configuration like this:
 
 ```yaml
 matrix_synapse_ext_spam_checker_synapse_simple_antispam_enabled: true