Minor cleanups

Fix incorrect indication in homeserver.yaml.j2
Add to_json to various Synapse tuning related configs
2025-07-08 09:04:31 +02:00 · 2024-01-17 10:53:20 +02:00 · 2024-01-17 10:53:12 +02:00 · 2024-01-17 10:34:20 +02:00 · 2024-01-17 10:32:25 +02:00 · 2024-01-17 10:32:25 +02:00
398 changed files with 1659 additions and 14318 deletions
--- a/.github/renovate.json
+++ b/.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
--- a/.github/workflows/matrix.yml
+++ b/.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
--- a/.gitignore
+++ b/.gitignore
@ -3,7 +3,7 @@
 .DS_Store
 .python-version
 .idea/
-.direnv/
+flake.lock
 # ignore roles pulled by ansible-galaxy
 /roles/galaxy/*
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -1,338 +1,3 @@
 # 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 `devture_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
 devture_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
@ -518,7 +183,7 @@ As mentioned above, static files like `/.well-known/matrix/*` or your base domai
 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.
+The playbook will migrate and update the files automatically. It will also warn you about usage of old variable names, so you can adapt to the new names.
 ### A note on performance
@ -540,17 +205,15 @@ If this is still not convincing enough for you and you want the best possible pe
 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.
+1. It will uninstall `matrix-nginx-proxy` for you and 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 an orphan (and unusable) `matrix-nginx-proxy` container and its data around. It will not let you continue using nginx for a while longer. You need to migrate - now!
-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.
+2. 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.
-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.
+3. 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.
-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.
+4. 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.
-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.
+5. 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.
 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.
@ -690,7 +353,7 @@ The **historical reasoning** behind this change is as follows:
 - 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.
- [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:
@ -854,7 +517,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.
@ -962,7 +625,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_`).
@ -970,7 +633,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_`).
@ -981,7 +644,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_`).
@ -992,7 +655,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_`).
@ -1105,7 +768,7 @@ 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 (`devture_traefik_config_entrypoint_web_secure_enabled: false`) and reverse-proxy to the Traefik server
@ -1132,7 +795,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.
@ -1176,7 +839,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.
@ -1273,7 +936,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.
@ -1542,7 +1205,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.
@ -1730,7 +1393,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.
@ -1871,7 +1534,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.
--- a/README.md
+++ b/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
@ -133,16 +135,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) |
+| [honoroit](https://gitlab.com/etke.cc/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) |
+| [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 +157,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 +165,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
--- a/YEAR-IN-REVIEW.md
+++ b/YEAR-IN-REVIEW.md
@ -17,7 +17,7 @@ This large Traefik reverse-proxy change was also accompanied by another internal
 [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).
+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://gitlab.com/etke.cc/tools/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**.
--- a/bin/ansible-all-hosts.sh
+++ b/bin/ansible-all-hosts.sh
@ -8,7 +8,7 @@
 #
 # set playbook root path
-root=$(dirname "$(readlink -f "$0")")/..
+root=$(dirname "$(readlink -f "$0")")/../..
 # set default tags or get from first argument if any
 tags="${1:-setup-all,start}"
--- a/bin/rebuild-mautrix-meta-instagram.sh
+++ b/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
--- a/docs/ansible.md
+++ b/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.16.1-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.16.1-r0-0
 ```
 The above command tries to mount an SSH key (`$HOME/.ssh/id_rsa`) into the container (at `/root/.ssh/id_rsa`).
--- a/docs/configuring-dns.md
+++ b/docs/configuring-dns.md
@ -79,7 +79,7 @@ The `cinny.<your-domain>` subdomain may be necessary, because this playbook coul
 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
--- a/docs/configuring-playbook-alertmanager-receiver.md
+++ b/docs/configuring-playbook-alertmanager-receiver.md
@ -1,93 +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.
 ## Configuration
 ```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 re-run the [installation](./installing.md) process (`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.
--- a/docs/configuring-playbook-appservice-double-puppet.md
+++ b/docs/configuring-playbook-appservice-double-puppet.md
@ -1,15 +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.
 To enable the Appservice Double Puppet service, adjust your `vars.yml` configuration like this and [re-run the playbook](./installing.md) (`just install-all`):
 ```yml
 matrix_appservice_double_puppet_enabled: true
 ```
 When enabled, double puppeting will automatically be enabled for all bridges that support double puppeting via the appservice method.
--- a/docs/configuring-playbook-appservice-draupnir-for-all.md
+++ b/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
 ```
--- a/docs/configuring-playbook-backup-borg.md
+++ b/docs/configuring-playbook-backup-borg.md
@ -64,7 +64,7 @@ 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
--- a/docs/configuring-playbook-base-domain-serving.md
+++ b/docs/configuring-playbook-base-domain-serving.md
@ -42,10 +42,6 @@ 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
 ```
 With this configuration, Ansible will no longer mess around with the `/matrix/static-files/public/index.html` file.
--- a/docs/configuring-playbook-bot-baibot.md
+++ b/docs/configuring-playbook-bot-baibot.md
@ -1,409 +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 use any string here. Consider generating it with `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
 # 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"
 # Uncomment and adjust 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"
 # Uncomment and adjust 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"
 # 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: You are a brief, but helpful bot.
          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: "You are an assistant based on the Llama3.1:8b model. Be brief in your responses."
        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 again:
 ```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
 ```
--- a/docs/configuring-playbook-bot-buscarron.md
+++ b/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.
@ -87,4 +87,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).
--- a/docs/configuring-playbook-bot-chatgpt.md
+++ b/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
--- a/docs/configuring-playbook-bot-draupnir.md
+++ b/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
@ -43,57 +40,14 @@ The following command works on semi up to date Windows 10 installs and All Windo
 ## 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 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
+## 5a. 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.
 Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
@ -107,7 +61,7 @@ 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.
 That is all you need to do due to that Draupnir can complete migration on its own.
@ -146,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:
+While this playbook uses reverse proxies, it does not yet implement this.
 ```yaml
 matrix_bot_draupnir_abuse_reporting_enabled: true
 ```
 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:
--- a/docs/configuring-playbook-bot-honoroit.md
+++ b/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
@ -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).
--- a/docs/configuring-playbook-bot-matrix-registration-bot.md
+++ b/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.
--- a/docs/configuring-playbook-bot-maubot.md
+++ b/docs/configuring-playbook-bot-maubot.md
@ -14,42 +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 again (`just install-all`):
+After configuring the playbook, run the [installation](installing.md) command again:
-**Notes**:
+```
-
+ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start
- 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.
 ## 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 
 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.
--- a/docs/configuring-playbook-bot-mjolnir.md
+++ b/docs/configuring-playbook-bot-mjolnir.md
@ -37,9 +37,7 @@ The following command works on semi up to date Windows 10 installs and All Windo
 ## 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 coping the internal room ID. The room ID will look something like `!QvgVuKq0ha8glOLGMG:DOMAIN`.
@ -48,47 +46,6 @@ Finally invite the `@bot.mjolnir:DOMAIN` account you created earlier into the ro
 ## 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.
--- a/docs/configuring-playbook-bot-postmoogle.md
+++ b/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. 
 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
@ -69,13 +69,13 @@ 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
--- a/docs/configuring-playbook-bridge-appservice-slack.md
+++ b/docs/configuring-playbook-bridge-appservice-slack.md
@ -20,24 +20,8 @@ matrix_appservice_slack_enabled: true
 matrix_appservice_slack_control_room_id: "Your matrix admin room id"
 ```
-3. Enable puppeting (optional, but recommended)
+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:
 ```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/
 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.
 5. Invite the bridge bot user into the admin room:
 ```
    /invite @slackbot:MY.DOMAIN
@ -45,7 +29,7 @@ matrix_appservice_slack_team_sync_enabled: true
 Note that the bot's domain is your server's domain **without the `matrix.` prefix.**
-6. 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 @@ Note that the bot's domain is your server's domain **without the `matrix.` prefi
    Click on bot users and add a new bot user. We will use this account to bridge the the rooms.
-7. 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 @@ Note that the bot's domain is your server's domain **without the `matrix.` prefi
    - reaction_added
    - reaction_removed
-8. Click on OAuth & Permissions and add the following scopes:
+7. Click on OAuth & Permissions and add the following scopes:
    - chat:write:bot
    - users:read
@ -75,9 +59,9 @@ Note that the bot's domain is your server's domain **without the `matrix.` prefi
    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.
-9. 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.
-10. 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.
@ -102,7 +86,7 @@ Note that the bot's domain is your server's domain **without the `matrix.` prefi
 Other configuration options are available via the `matrix_appservice_slack_configuration_extension_yaml` variable.
-11. Unlinking
+10. Unlinking
    Channels can be unlinked again like this:
    ```
--- a/docs/configuring-playbook-bridge-beeper-linkedin.md
+++ b/docs/configuring-playbook-bridge-beeper-linkedin.md
@ -30,13 +30,11 @@ 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.
-## Set up Double Puppeting by enabling Appservice Double Puppet or Shared Secret Auth
+## Set up Double Puppeting
-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.
+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.
-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.
+The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
 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.
 ## Usage
--- a/docs/configuring-playbook-bridge-heisenbridge.md
+++ b/docs/configuring-playbook-bridge-heisenbridge.md
@ -22,8 +22,6 @@ 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.
--- a/docs/configuring-playbook-bridge-hookshot.md
+++ b/docs/configuring-playbook-bridge-hookshot.md
@ -50,8 +50,7 @@ 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 |
+| webhooks | `/hookshot/webhooks/` | `matrix_hookshot_webhook_endpoint` | generics, GitHub "Webhook URL", GitLab "URL", etc. |
 | generic | `/hookshot/webhooks/webhook` | `matrix_hookshot_generic_endpoint` | Generic webhooks |
 | 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 |
--- a/docs/configuring-playbook-bridge-mautrix-discord.md
+++ b/docs/configuring-playbook-bridge-mautrix-discord.md
@ -44,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.
+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.
 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.
 #### Method 2: manually, by asking each user to provide a working access token
--- a/docs/configuring-playbook-bridge-mautrix-facebook.md
+++ b/docs/configuring-playbook-bridge-mautrix-facebook.md
@ -1,7 +1,5 @@
 # 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.
--- a/docs/configuring-playbook-bridge-mautrix-gmessages.md
+++ b/docs/configuring-playbook-bridge-mautrix-gmessages.md
@ -14,13 +14,11 @@ matrix_mautrix_gmessages_enabled: true
 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.
+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.
 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.
 ### Method 2: manually, by asking each user to provide a working access token
--- a/docs/configuring-playbook-bridge-mautrix-googlechat.md
+++ b/docs/configuring-playbook-bridge-mautrix-googlechat.md
@ -16,13 +16,11 @@ matrix_mautrix_googlechat_enabled: true
 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.
+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.
 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.
 ### Method 2: manually, by asking each user to provide a working access token
--- a/docs/configuring-playbook-bridge-mautrix-instagram.md
+++ b/docs/configuring-playbook-bridge-mautrix-instagram.md
@ -1,7 +1,5 @@
 # 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.
--- a/docs/configuring-playbook-bridge-mautrix-meta-instagram.md
+++ b/docs/configuring-playbook-bridge-mautrix-meta-instagram.md
@ -1,92 +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.
 ## Configuration
 Most simply, you can enable the bridge with the following playbook configuration:
 ```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.
 ## 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
 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.
 ### 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).
--- a/docs/configuring-playbook-bridge-mautrix-meta-messenger.md
+++ b/docs/configuring-playbook-bridge-mautrix-meta-messenger.md
@ -1,107 +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.
 ## Configuration
 Most simply, you can enable the bridge with the following playbook configuration:
 ```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.
 ## 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
 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.
 ### 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).
--- a/docs/configuring-playbook-bridge-mautrix-signal.md
+++ b/docs/configuring-playbook-bridge-mautrix-signal.md
@ -45,7 +45,7 @@ This will add the admin permission to the specific user, while keeping the defau
 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
 ```
@ -56,9 +56,9 @@ You may wish to look at `roles/custom/matrix-bridge-mautrix-signal/templates/con
 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.
--- a/docs/configuring-playbook-bridge-mautrix-slack.md
+++ b/docs/configuring-playbook-bridge-mautrix-slack.md
@ -47,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.
--- a/docs/configuring-playbook-bridge-mautrix-telegram.md
+++ b/docs/configuring-playbook-bridge-mautrix-telegram.md
@ -16,13 +16,11 @@ matrix_mautrix_telegram_api_hash: YOUR_TELEGRAM_API_HASH
 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.
+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.
 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.
 ### Method 2: manually, by asking each user to provide a working access token
--- a/docs/configuring-playbook-bridge-mautrix-twitter.md
+++ b/docs/configuring-playbook-bridge-mautrix-twitter.md
@ -15,13 +15,11 @@ matrix_mautrix_twitter_enabled: true
 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.
+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.
 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.
 ### Method 2: manually, by asking each user to provide a working access token
--- a/docs/configuring-playbook-bridge-mautrix-whatsapp.md
+++ b/docs/configuring-playbook-bridge-mautrix-whatsapp.md
@ -24,17 +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.
 ## 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:
 ```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.
+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.
 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.
 ### Method 2: manually, by asking each user to provide a working access token
--- a/docs/configuring-playbook-bridge-wechat.md
+++ b/docs/configuring-playbook-bridge-wechat.md
@ -1,17 +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.
 To enable the bridge, use the following playbook configuration and re-run the playbook's [installation](./installing.md) procedure:
 ```yaml
 matrix_wechat_enabled: true
 ```
 ## 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.
--- a/docs/configuring-playbook-client-schildichat.md
+++ b/docs/configuring-playbook-client-schildichat.md
@ -2,7 +2,7 @@
 By default, this playbook does not install the [SchildiChat](https://github.com/SchildiChat/schildichat-desktop) Matrix client web application.
-**WARNING**: SchildiChat is based on Element-web, but its releases are lagging behind. As an example (from 2024-02-26), SchildiChat 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 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!
 ## Enabling SchildiChat
--- a/docs/configuring-playbook-federation.md
+++ b/docs/configuring-playbook-federation.md
@ -54,6 +54,7 @@ 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.
 **NOTE**: this approach hasn't been tested with the new Traefik-only setup that the playbook started using in 2024-01. It may not work.
 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:
--- a/docs/configuring-playbook-matrix-media-repo.md
+++ b/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
@ -89,26 +89,6 @@ matrix_media_repo_datastore_s3_opts_bucket_name: "your-media-bucket"
 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.
--- a/docs/configuring-playbook-mautrix-bridges.md
+++ b/docs/configuring-playbook-mautrix-bridges.md
@ -40,14 +40,16 @@ Encryption support is off by default. If you would like to enable encryption, ad
 ```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_configuration_extension_yaml: |
-matrix_mautrix_SERVICENAME_bridge_encryption_default: true
+  bridge:
    encryption:
      allow: true
      default: true
 ```
 ## relay mode
@ -96,14 +98,19 @@ You may wish to look at `roles/custom/matrix-bridge-mautrix-SERVICENAME/template
 ## 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
--- a/docs/configuring-playbook-ntfy.md
+++ b/docs/configuring-playbook-ntfy.md
@ -29,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).
--- a/docs/configuring-playbook-own-webserver.md
+++ b/docs/configuring-playbook-own-webserver.md
@ -169,15 +169,7 @@ devture_traefik_config_entrypoint_web_forwardedHeaders_insecure: true
 # 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'
+matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port: 127.0.0.1:8449
 # 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.
@ -189,7 +181,7 @@ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_custom:
 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).
+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).
 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.
--- a/docs/configuring-playbook-pantalaimon.md
+++ b/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.
--- a/docs/configuring-playbook-prometheus-grafana.md
+++ b/docs/configuring-playbook-prometheus-grafana.md
@ -79,8 +79,6 @@ Name | Description
 `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_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.
@ -121,8 +119,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://github.com/element-hq/synapse/wiki/Understanding-Synapse-Performance-Issues-Through-Grafana-Graphs) at the Synapse Github Wiki
 - [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)
 - [The Node Exporter dashboard](https://github.com/rfrail3/grafana-dashboards) (for generic non-synapse performance graphs)
--- a/docs/configuring-playbook-sliding-sync-proxy.md
+++ b/docs/configuring-playbook-sliding-sync-proxy.md
@ -23,7 +23,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
--- a/docs/configuring-playbook-ssl-certificates.md
+++ b/docs/configuring-playbook-ssl-certificates.md
@ -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
 devture_traefik_config_certificatesResolvers_acme_dnsChallenge_enabled: true
 devture_traefik_config_certificatesResolvers_acme_dnsChallenge_provider: "cloudflare"
 devture_traefik_config_certificatesResolvers_acme_dnsChallenge_delayBeforeCheck: 60
 devture_traefik_config_certificatesResolvers_acme_dnsChallenge_resolvers:
  - "1.1.1.1:53"
 devture_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.
--- a/docs/configuring-playbook-synapse-admin.md
+++ b/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**. It's designed to work with the Synapse homeserver implementation, but to some extent may work with [Dendrite](./configuring-playbook-dendrite.md) as well.
-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,19 @@ 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:
+**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/element-hq/synapse/blob/master/docs/reverse_proxy.md#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 Synapse (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.
 ## Installing
-After configuring the playbook, run the [installation](installing.md) command again (`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 +35,5 @@ After configuring the playbook, run the [installation](installing.md) command ag
 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`
--- a/docs/configuring-playbook-synapse-auto-accept-invite.md
+++ b/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, you need a configuration like this:
 ```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 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'
 ```
--- a/docs/configuring-playbook-synapse-usage-exporter.md
+++ b/docs/configuring-playbook-synapse-usage-exporter.md
@ -1,26 +0,0 @@
 # Setting up synapse-usage-exporter (optional)
 [synapse-usage-exporter](https://github.com/loelkes/synapse-usage-exporter) allows you to export the usage statistics of a Synapse homeserver to this container service and for the collected metrics to later be scraped by Prometheus.
 Synapse does not include usage statistics in its Prometheus metrics. They can be reported to an HTTP `PUT` endpoint 5 minutes after startup and from then on at a fixed interval of once every three hours. This role integrates a simple [Flask](https://flask.palletsprojects.com) project that offers an HTTP `PUT` endpoint and holds the most recent received record available to be scraped by Prometheus.
 Enabling this service will automatically:
 - install the synapse-usage-exporter service
 - re-configure Synapse to push (via HTTP `PUT`) usage statistics information to synapse-usage-exporter
 - re-configure [Prometheus](./configuring-playbook-prometheus-grafana.md) (if Prometheus is enabled), to periodically scrape metrics from synapse-usage-exporter
 - add a new [Grafana](./configuring-playbook-prometheus-grafana.md) dashboard (if Grafana is enabled) containing Synapse usage statistics
 ## Quickstart
 Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file and [re-run the installation process](./installing.md) for the playbook:
 ```yaml
 matrix_synapse_usage_exporter_enabled: true
 # (Optional) Expose endpoint if you want to collect statistics from outside (from other homeservers).
 # If enabled, synapse-usage-exporter will be exposed publicly at `matrix.DOMAIN/report-usage-stats/push`.
 # When collecting usage statistics for Synapse running on the same host, you don't need to enable this.
 # You can adjust the hostname and path via `matrix_synapse_usage_exporter_hostname` and `matrix_synapse_usage_exporter_path_prefix`.
 # matrix_synapse_usage_exporter_proxying_enabled: true
 ```
--- a/docs/configuring-playbook-synapse.md
+++ b/docs/configuring-playbook-synapse.md
@ -20,65 +20,22 @@ Alternatively, **if there is no pre-defined variable** for a Synapse setting you
 ## Load balancing with workers
-To have Synapse gracefully handle thousands of users, worker support should be enabled. It factors out some homeserver tasks and spreads the load of incoming client and server-to-server traffic between multiple processes. More information can be found in the [official Synapse workers documentation](https://github.com/element-hq/synapse/blob/master/docs/workers.md) and [Tom Foster](https://github.com/tcpipuk)'s [Synapse homeserver guide](https://tcpipuk.github.io/synapse/index.html).
+To have Synapse gracefully handle thousands of users, worker support should be enabled. It factors out some homeserver tasks and spreads the load of incoming client and server-to-server traffic between multiple processes. More information can be found in the [official Synapse workers documentation](https://github.com/element-hq/synapse/blob/master/docs/workers.md).
 To enable Synapse worker support, update your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:
 ```yaml
 matrix_synapse_workers_enabled: true
 matrix_synapse_workers_preset: one-of-each
 ```
-By default, this enables the `one-of-each` [worker preset](#worker-presets), but you may wish to use another preset or [control the number of worker instances](#controlling-the-number-of-worker-instances).
+We support a few configuration presets (`matrix_synapse_workers_preset: one-of-each` being the default configuration):
 - `little-federation-helper` - a very minimal worker configuration to improve federation performance
 - `one-of-each` - one worker of each supported type
-### Worker presets
+If you'd like more customization power, you can start with one of the presets and tweak various `matrix_synapse_workers_*_count` variables manually.
 We support a few configuration presets (`matrix_synapse_workers_preset: one-of-each` being the default configuration right now):
 - (federation-only) `little-federation-helper` - a very minimal worker configuration to improve federation performance
 - (generic) `one-of-each` - defaults to one worker of each supported type - no smart routing, just generic workers
 - (specialized) `specialized-workers` - defaults to one worker of each supported type, but disables generic workers and uses [specialized workers](#specialized-workers) instead
 These presets represent a few common configurations. There are many worker types which can be mixed and matched based on your needs.
 #### Generic workers
 Previously, the playbook only supported the most basic type of load-balancing. We call it **generic load-balancing** below, because incoming HTTP requests are sent to a generic worker. Load-balancing was done based on the requestor's IP address. This is simple, but not necessarily optimal. If you're accessing your account from multiple IP addresses (e.g. your mobile phone being on a different network than your PC), these separate requests may potentially be routed to different workers, each of which would need to cache roughly the same data.
 This is **still the default load-balancing method (preset) used by the playbook**.
 To use generic load-balancing, do not specify `matrix_synapse_workers_preset` to make it use the default value (`one-of-each`), or better yet - explicitly set it as `one-of-each`.
 You may also consider [tweaking the number of workers of each type](#controlling-the-number-of-worker-instances) from the default (one of each).
 #### Specialized workers
 The playbook now supports a smarter **specialized load-balancing** inspired by [Tom Foster](https://github.com/tcpipuk)'s [Synapse homeserver guide](https://tcpipuk.github.io/synapse/index.html). Instead of routing requests to one or more [generic workers](#generic-workers) based only on the requestor's IP adddress, specialized load-balancing routes to **4 different types of specialized workers** based on **smarter criteria** - the access token (username) of the requestor and/or on the resource (room, etc.) being requested.
 The playbook supports these **4 types** of specialized workers:
 - Room workers - handles various [Client-Server](https://spec.matrix.org/v1.9/client-server-api/) & [Federation](https://spec.matrix.org/v1.9/server-server-api) APIs dedicated to handling specific rooms
 - Sync workers - handles various [Client-Server](https://spec.matrix.org/v1.9/client-server-api/) APIs related to synchronization (most notably [the `/sync` endpoint](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3sync))
 - Client readers - handles various [Client-Server](https://spec.matrix.org/v1.9/client-server-api/) APIs which are not for specific rooms (handled by **room workers**) or for synchronization (handled by **sync workers**)
 - Federation readers - handles various [Federation](https://spec.matrix.org/v1.9/server-server-api) APIs which are not for specific rooms (handled by **room workers**)
 To use specialized load-balancing, consider enabling the `specialized-workers` [worker preset](#worker-presets) and potentially [tweaking the number of workers of each type](#controlling-the-number-of-worker-instances) from the default (one of each).
 #### Controlling the number of worker instances
 If you'd like more customization power, you can start with one of the [worker presets](#worker-presets) and then tweak various `matrix_synapse_workers_*_count` variables manually.
 To find what variables are available for you to override in your own `vars.yml` configuration file, see the [`defaults/main.yml` file for the `matrix-synapse` Ansible role](../roles/custom/matrix-synapse/defaults/main.yml).
 The only thing you **cannot** do is mix [generic workers](#generic-workers) and [specialized workers](#specialized-workers).
 #### Effect of enabling workers on the rest of your server
 When Synapse workers are enabled, the integrated [Postgres database is tuned](maintenance-postgres.md#tuning-postgresql), so that the maximum number of Postgres connections are increased from `200` to `500`. If you need to decrease or increase the number of maximum Postgres connections further, use the `devture_postgres_max_connections` variable.
 A separate Ansible role (`matrix-synapse-reverse-proxy-companion`) and component handles load-balancing for workers. This role/component is automatically enabled when you enable workers. Make sure to use the `setup-all` tag (not `install-all`!) during the playbook's [installation](./installing.md) process, especially if you're disabling workers, so that components may be installed/uninstalled correctly.
 In case any problems occur, make sure to have a look at the [list of synapse issues about workers](https://github.com/matrix-org/synapse/issues?q=workers+in%3Atitle) and your `journalctl --unit 'matrix-*'`.
@ -116,6 +73,8 @@ matrix_synapse_oidc_providers:
    backchannel_logout_enabled: true # Optional
 ```
 **NOTE**: if you inject the OIDC configuration using `matrix_synapse_configuration_extension_yaml` (instead of `matrix_synapse_oidc_enabled: true` + `matrix_synapse_oidc_providers` as explained above), then the OIDC routes (`/_synapse/oidc`) will not be publicly exposed automatically. In such a case, you'd need to expose them manually by toggling: `matrix_synapse_container_labels_public_client_synapse_oidc_api_enabled: true`.
 ## Customizing templates
@ -161,6 +120,4 @@ Due to this, it's recommended to only store and maintain template files in your
 This playbook allows you to enable Synapse metrics, which can provide insight into the performance and activity of Synapse.
-To enable Synapse runtime metrics see: [Enabling metrics and graphs (Prometheus, Grafana) for your Matrix server](configuring-playbook-prometheus-grafana.md)
+To enable Synapse metrics see [`configuring-playbook-prometheus-grafana.md`](./configuring-playbook-prometheus-grafana.md)
 To enable Synapse usage metrics, see: [Enabling synapse-usage-exporter for Synapse usage statistics](configuring-playbook-synapse-usage-exporter.md)
--- a/docs/configuring-playbook-traefik.md
+++ b/docs/configuring-playbook-traefik.md
@ -35,7 +35,7 @@ devture_traefik_dashboard_basicauth_user: YOUR_USERNAME_HERE
 devture_traefik_dashboard_basicauth_password: YOUR_PASSWORD_HERE
 ```
-**WARNING**: Enabling the dashboard on a hostname you use for something else (like `matrix_server_fqn_matrix` in the configuration above) may cause conflicts. Enabling the Traefik Dashboard makes Traefik capture all `/dashboard` and `/api` requests and forward them to itself. If any of the services hosted on the same hostname requires any of these 2 URL prefixes, you will experience problems. So far, we're not aware of any playbook services which occupy these endpoints and are likely to cause conflicts.
+**WARNING**: enabling the dashboard on a hostname you use for something else (like `matrix_server_fqn_matrix` in the configuration above) may cause conflicts. Enabling the Traefik Dashboard makes Traefik capture all `/dashboard` and `/api` requests and forward them to itself. If any of the services hosted on the same hostname requires any of these 2 URL prefixes, you will experience problems. So far, we're not aware of any playbook services which occupy these endpoints and are likely to cause conflicts.
 ## Additional configuration
@ -48,114 +48,3 @@ devture_traefik_configuration_extension_yaml: |
  api:
    dashboard: true
 ```
 ## Reverse-proxying another service behind Traefik
 The preferred way to reverse-proxy additional services behind Traefik would be to start the service as another container, configure the container with the corresponding Traefik [container labels](https://docs.docker.com/config/labels-custom-metadata/) (see [Traefik & Docker](https://doc.traefik.io/traefik/routing/providers/docker/)), and connect the service to the `traefik` network. Some services are also already available via the compatible [mash-playbook](https://github.com/mother-of-all-self-hosting/mash-playbook), but take a look at the minor [interoperability adjustments](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/interoperability.md).
 However, if your service does not run on a container or runs on another machine, the following configuration might be what you are looking for.
 ## Reverse-proxying a remote HTTP/HTTPS service behind Traefik
 If you want to host another webserver would be reachable via `my-fancy-website.mydomain.com` from the internet and via `https://<internal webserver IP address>:<internal port>` from inside your network, you can make the playbook's integrated Traefik instance reverse-proxy the traffic to the correct host.
 Prerequisites: DNS and routing for the domain `my-fancy-website.mydomain.com` need to be set up correctly. In this case, you'd be pointing the domain name to your Matrix server - `my-fancy-website.mydomain.com` would be a CNAME going to `matrix.example.com`.
 First, we have to adjust the static configuration of Traefik, so that we can add additional configuration files:
 ```yaml
 # We enable all config files in the /config/ folder to be loaded.
 # `/config` is the path as it appears in the Traefik container.
 # On the host, it's actually `/matrix/traefik/config` (as defined in `devture_traefik_config_dir_path`).
 devture_traefik_configuration_extension_yaml: |
  providers:
    file:
      directory: /config/
      watch: true
      filename: ""
 ```
 If you are using a self-signed certificate on your webserver, you can tell Traefik to trust your own backend servers by adding more configuration to the static configuration file. If you do so, bear in mind the security implications of disabling the certificate validity checks towards your back end.
 ```yaml
 # We enable all config files in the /config/ folder to be loaded and
 devture_traefik_configuration_extension_yaml: |
  providers:
    file:
      directory: /config/
      watch: true
      filename: ""
  serversTransport:
    insecureSkipVerify: true
 ```
 Next, you have to add a new dynamic configuration file for Traefik that contains the actual information of the server using the `aux_file_definitions` variable. In this example, we will terminate SSL at the Traefik instance and connect to the other server via HTTPS. Traefik will now take care of managing the certificates. 
 ```yaml
 aux_file_definitions:
  - dest: "{{ devture_traefik_config_dir_path }}/provider_my_fancy_website.yml"
    content: |
      http:
        routers:
          webserver-router:
            rule: Host(`my_fancy_website.mydomain.com`)
            service: webserver-service
            tls:
              certResolver: default
        services:
          webserver-service:
            loadBalancer:
              servers:
                - url: "https://<internal webserver IP address>:<internal port>"
 ```
 Changing the `url` to one with an `http://` prefix would allow to connect to the server via HTTP.
 ## Reverse-proxying another service behind Traefik without terminating SSL
 If you do not want to terminate SSL at the Traefik instance (for example, because you're already terminating SSL at other webserver), you need to adjust the static configuration in the same way as in the previous chapter in order to be able to add our own dynamic configuration files. Afterwards, you can add the following configuration to your `vars.yml` configuration file:
 ```yaml
 aux_file_definitions:
  - dest: "{{ devture_traefik_config_dir_path }}/providers_my_fancy_website.yml"
    content: |
      tcp:
        routers:
          webserver-router:
            rule: Host(`my_fancy_website.mydomain.com`)
            service: webserver-service
            tls:
              passthrough: true
        services:
          webserver-service:
            loadBalancer:
              servers:
                - url: "https://<internal webserver IP address>:<internal port>"
 ```
 Changing the `url` to one with an `http://` prefix would allow to connect to the server via HTTP.
 With these changes, all TCP traffic will be reverse-proxied to the target system. 
 **WARNING**: This configuration might lead to problems or need additional steps when a [certbot](https://certbot.eff.org/) behind Traefik also tries to manage [Let's Encrypt](https://letsencrypt.org/) certificates, as Traefik captures all traffic to ```PathPrefix(`/.well-known/acme-challenge/`)```. 
 ## Traefik behind a `proxy_protocol` reverse-proxy
 If you run a reverse-proxy which speaks `proxy_protocol`, add the following to your configuration file:
 ```yaml
 devture_traefik_configuration_extension_yaml: |
  entryPoints:
    web-secure:
      proxyProtocol:
        trustedIPs:
          - "127.0.0.1/32"
          - "<proxy internal IPv4>/32"
          - "<proxy IPv6>/128"
    matrix-federation:
        proxyProtocol:
          trustedIPs:
            - "127.0.0.1/32"
            - "<proxy internal IPv4>/32"
            - "<proxy IPv6>/128"
 ```
--- a/docs/configuring-playbook-turn.md
+++ b/docs/configuring-playbook-turn.md
@ -34,21 +34,6 @@ If your server has multiple external IP addresses, the Coturn role offers a diff
 matrix_coturn_turn_external_ip_addresses: ['1.2.3.4', '4.5.6.7']
 ```
 ## Changing the authentication mechanism
 The playbook uses the [`auth-secret` authentication method](https://github.com/coturn/coturn/blob/873cabd6a2e5edd7e9cc5662cac3ffe47fe87a8e/README.turnserver#L186-L199) by default, but you may switch to the [`lt-cred-mech` method](https://github.com/coturn/coturn/blob/873cabd6a2e5edd7e9cc5662cac3ffe47fe87a8e/README.turnserver#L178) which [some report](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3191) to be working better.
 To do so, add this override to your configuration:
 ```yml
 matrix_coturn_authentication_method: lt-cred-mech
 ```
 Regardless of the selected authentication method, the playbook generates secrets automatically and passes them to the homeserver and Coturn.
 If you're using [Jitsi](./configuring-playbook-jitsi.md), note that switching to `lt-cred-mech` will remove the integration between Jitsi and your own Coturn server, because Jitsi only seems to support the `auth-secret` authentication method.
 ## Using your own external Coturn server
 If you'd like to use another TURN server (be it Coturn or some other one), you can configure the playbook like this:
--- a/docs/configuring-playbook.md
+++ b/docs/configuring-playbook.md
@ -8,7 +8,7 @@ To configure the playbook, you need to have done the following things:
 You can then follow these steps inside the playbook directory:
-1. create a directory to hold your configuration (`mkdir -p inventory/host_vars/matrix.<your-domain>`)
+1. create a directory to hold your configuration (`mkdir inventory/host_vars/matrix.<your-domain>`)
 1. copy the sample configuration file (`cp examples/vars.yml inventory/host_vars/matrix.<your-domain>/vars.yml`)
@ -42,8 +42,6 @@ When you're done with all the configuration you'd like to do, continue with [Ins
 - [Enabling metrics and graphs (Prometheus, Grafana) for your Matrix server](configuring-playbook-prometheus-grafana.md) (optional)
 - [Enabling synapse-usage-exporter for Synapse usage statistics](configuring-playbook-synapse-usage-exporter.md) (optional)
 ### Core service adjustments
 - Homeserver configuration:
@ -89,8 +87,6 @@ When you're done with all the configuration you'd like to do, continue with [Ins
 ### Authentication and user-related
 - [Setting up Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) (optional)
 - [Setting up an ma1sd Identity Server](configuring-playbook-ma1sd.md) (optional)
 - [Setting up Synapse Admin](configuring-playbook-synapse-admin.md) (optional)
@ -109,9 +105,7 @@ When you're done with all the configuration you'd like to do, continue with [Ins
 - [Setting up Matrix Corporal](configuring-playbook-matrix-corporal.md) (optional, advanced)
- [Setting up Matrix User Verification Service](configuring-playbook-user-verification-service.md) (optional, advanced)
+- [Matrix User Verification Service](configuring-playbook-user-verification-service.md) (optional, advanced)
 - [Setting up Pantalaimon (E2EE aware proxy daemon)](configuring-playbook-pantalaimon.md) (optional, advanced)
 ### Bridging other networks
@ -126,17 +120,13 @@ When you're done with all the configuration you'd like to do, continue with [Ins
 - [Setting up Mautrix Whatsapp bridging](configuring-playbook-bridge-mautrix-whatsapp.md) (optional)
- [Setting up Instagram bridging via Mautrix Meta](configuring-playbook-bridge-mautrix-meta-instagram.md) (optional)
+- [Setting up Mautrix Facebook bridging](configuring-playbook-bridge-mautrix-facebook.md) (optional)
 - [Setting up Messenger bridging via Mautrix Meta](configuring-playbook-bridge-mautrix-meta-messenger.md) (optional)
 - ~~[Setting up Mautrix Facebook bridging](configuring-playbook-bridge-mautrix-facebook.md)~~ - consider bridging to Facebook/Messenger using the new [mautrix-meta-messenger](./configuring-playbook-bridge-mautrix-meta-messenger.md) bridge (optional)
 - [Setting up Mautrix Hangouts bridging](configuring-playbook-bridge-mautrix-hangouts.md) (optional)
 - [Setting up Mautrix Google Chat bridging](configuring-playbook-bridge-mautrix-googlechat.md) (optional)
- ~~[Setting up Mautrix Instagram bridging](configuring-playbook-bridge-mautrix-instagram.md)~~ - consider bridging to Instagram using the new [mautrix-meta-instagram](./configuring-playbook-bridge-mautrix-meta-instagram.md) bridge (optional)
+- [Setting up Mautrix Instagram bridging](configuring-playbook-bridge-mautrix-instagram.md) (optional)
 - [Setting up Mautrix Twitter bridging](configuring-playbook-bridge-mautrix-twitter.md) (optional)
@ -182,14 +172,10 @@ When you're done with all the configuration you'd like to do, continue with [Ins
 - [Setting up Heisenbridge bouncer-style IRC bridging](configuring-playbook-bridge-heisenbridge.md) (optional)
 - [Setting up WeChat bridging](configuring-playbook-bridge-wechat.md) (optional)
 ### Bots
- [Setting up baibot](configuring-playbook-bot-baibot.md) - a bot through which you can talk to various [AI](https://en.wikipedia.org/wiki/Artificial_intelligence) / [Large Language Models](https://en.wikipedia.org/wiki/Large_language_model) services ([OpenAI](https://openai.com/)'s [ChatGPT](https://openai.com/blog/chatgpt/) and [others](https://github.com/etkecc/baibot/blob/main/docs/providers.md)) (optional)
+- [Setting up matrix-bot-chatgpt](configuring-playbook-bot-chatgpt.md) - a bot through which you can talk to the [ChatGPT](https://openai.com/blog/chatgpt/) model(optional)
 - [Setting up matrix-bot-chatgpt](configuring-playbook-bot-chatgpt.md) - a bot through which you can talk to the [ChatGPT](https://openai.com/blog/chatgpt/) model (optional)
 - [Setting up matrix-reminder-bot](configuring-playbook-bot-matrix-reminder-bot.md) - a bot to remind you about stuff (optional)
@ -205,8 +191,6 @@ When you're done with all the configuration you'd like to do, continue with [Ins
 - [Setting up Draupnir](configuring-playbook-bot-draupnir.md) - a moderation tool/bot, forked from Mjolnir and maintained by its former leader developer (optional)
 - [Setting up Draupnir for all](configuring-playbook-appservice-draupnir-for-all.md) - like the [Draupnir bot](configuring-playbook-bot-draupnir.md) mentioned above, but running in appservice mode and supporting multiple instances (optional)
 - [Setting up Buscarron](configuring-playbook-bot-buscarron.md) - a bot you can use to send any form (HTTP POST, HTML) to a (encrypted) Matrix room (optional)
@ -230,5 +214,3 @@ When you're done with all the configuration you'd like to do, continue with [Ins
 - [Setting up a Cactus Comments server](configuring-playbook-cactus-comments.md) - a federated comment system built on Matrix (optional)
 - [Setting up the Rageshake bug report server](configuring-playbook-rageshake.md) (optional)
 - [Setting up Prometheus Alertmanager integration via matrix-alertmanager-receiver](configuring-playbook-alertmanager-receiver.md) (optional)
--- a/docs/container-images.md
+++ b/docs/container-images.md
@ -100,16 +100,14 @@ These services are not part of our default installation, but can be enabled by [
 - [dock.mau.dev/maubot/maubot](https://mau.dev/maubot/maubot/container_registry) - the [maubot](https://github.com/maubot/maubot) bot (a plugin-based Matrix bot system) (optional)
- [etke.cc/honoroit](https://github.com/etkecc/honoroit/container_registry) - the [honoroit](https://github.com/etkecc/honoroit) helpdesk bot (optional)
+- [etke.cc/honoroit](https://gitlab.com/etke.cc/honoroit/container_registry) - the [honoroit](https://gitlab.com/etke.cc/honoroit) helpdesk bot (optional)
- [etke.cc/postmoogle](https://github.com/etkecc/postmoogle/container_registry) - the [Postmoogle](https://github.com/etkecc/postmoogle) email bridge bot (optional)
+- [etke.cc/postmoogle](https://gitlab.com/etke.cc/postmoogle/container_registry) - the [Postmoogle](https://gitlab.com/etke.cc/postmoogle) email bridge bot (optional)
 - [matrixdotorg/go-neb](https://hub.docker.com/r/matrixdotorg/go-neb) - the [Go-NEB](https://github.com/matrix-org/go-neb) bot (optional)
 - [matrixdotorg/mjolnir](https://hub.docker.com/r/matrixdotorg/mjolnir) - the [mjolnir](https://github.com/matrix-org/mjolnir) moderation bot (optional)
 - [gnuxie/draupnir](https://hub.docker.com/r/gnuxie/draupnir) - the [Draupnir](https://github.com/the-draupnir-project/Draupnir/) moderation bot (optional)
 - [awesometechnologies/synapse-admin](https://hub.docker.com/r/awesometechnologies/synapse-admin) - the [synapse-admin](https://github.com/Awesome-Technologies/synapse-admin) web UI tool for administrating users and rooms on your Matrix server (optional)
 - [prom/prometheus](https://hub.docker.com/r/prom/prometheus/) - [Prometheus](https://github.com/prometheus/prometheus/) is a systems and service monitoring system
--- a/docs/faq.md
+++ b/docs/faq.md
@ -342,7 +342,7 @@ As described in [How is the effective configuration determined?](#how-is-the-eff
 Refer to both of these for inspiration. Still, as mentioned in [Configuring the playbook](configuring-playbook.md), you're only ever supposed to edit your own `inventory/host_vars/matrix.DOMAIN/vars.yml` file and nothing else inside the playbook (unless you're meaning to contribute new features).
-**Note**: some of the roles (`roles/galaxy/*`) live in separate repositories and are only installed after your run `just roles` (or `make roles`) or `just update` (which automatically does `git pull` and `just roles`).
+**Note**: some of the roles (`roles/galaxy/*`) live in separate repositories and are only installed after your run `just roles` (or `make roles`).
 ### I'd like to adjust some configuration which doesn't have a corresponding variable. How do I do it?
@ -356,7 +356,7 @@ Besides that, each role (component) aims to provide a `matrix_SOME_COMPONENT_con
 Check each role's `roles/*/*/defaults/main.yml` for the corresponding variable and an example for how use it.
-**Note**: some of the roles (`roles/galaxy/*`) live in separate repositories and are only installed after your run `just roles` (or `make roles`) or `just update` (which automatically does `git pull` and `just roles`).
+**Note**: some of the roles (`roles/galaxy/*`) live in separate repositories and are only installed after your run `just roles` (or `make roles`).
 ## Installation
--- a/docs/howto-srv-server-delegation.md
+++ b/docs/howto-srv-server-delegation.md
@ -27,7 +27,7 @@ Also, all instructions below are from an older version of the playbook and may n
 ```yaml
 # To serve the federation from any domain, as long as the path matches
-matrix_synapse_container_labels_public_federation_api_traefik_rule: PathPrefix(`/_matrix/`)
+matrix_synapse_container_labels_public_federation_api_traefik_rule: PathPrefix(`/_matrix/federation`)
 ```
 This is because with SRV federation, some servers / tools (one of which being the federation tester) try to access the federation API using the resolved IP address instead of the domain name (or they are not using SNI). This change will make Traefik route all traffic for which the path match this rule go to the federation endpoint.
--- a/docs/installing.md
+++ b/docs/installing.md
@ -2,9 +2,7 @@
 If you've [configured your DNS](configuring-dns.md) and have [configured the playbook](configuring-playbook.md), you can start the installation procedure.
-**Before installing** and each time you update the playbook in the future, you will need to update the Ansible roles in this playbook by running `just roles`. `just roles` is a shortcut (a `roles` target defined in [`justfile`](../justfile) and executed by the [`just`](https://github.com/casey/just) utility) which ultimately runs [agru](https://github.com/etkecc/agru) or [ansible-galaxy](https://docs.ansible.com/ansible/latest/cli/ansible-galaxy.html) (depending on what is available in your system) to download Ansible roles. If you don't have `just`, you can also manually run the `roles` commands seen in the `justfile`.
+**Before installing** and each time you update the playbook in the future, you will need to update the Ansible roles in this playbook by running `just roles`. `just roles` is a shortcut (a `roles` target defined in [`justfile`](../justfile) and executed by the [`just`](https://github.com/casey/just) utility) which ultimately runs [ansible-galaxy](https://docs.ansible.com/ansible/latest/cli/ansible-galaxy.html) to download Ansible roles. If you don't have `just`, you can also manually run the `roles` commands seen in the `justfile`.
 There's another shortcut (`just update`) which updates the playbook (`git pull`) and updates roles (`just update`) at the same time.
 ## Playbook tags introduction
--- a/docs/maintenance-migrating.md
+++ b/docs/maintenance-migrating.md
@ -1,6 +1,6 @@
 > **Note**: This migration guide is applicable if you migrate from one server to another server having the same CPU architecture (e.g. both servers being `amd64`). 
 > 
-> If you're trying to migrate between different architectures (e.g. `amd64` --> `arm64`), simply copying the complete `/matrix` directory is not possible as it would move the raw PostgreSQL data (`/matrix/postgres/data`) between different architectures. In this specific case, you can use the guide below as a reference, but you would also need to avoid syncing `/matrix/postgres/data` to the new host, and also dump the database on your current server and import it properly on the new server. See our [Backing up PostgreSQL](maintenance-postgres.md#backing-up-postgresql) docs for help with PostgreSQL backup/restore.
+> If you're trying to migrate between different architectures (e.g. `amd64` --> `arm64`), simply copying the complete `/matrix` directory is not possible as it would move the raw PostgreSQL data between different architectures. In this specific case, you can use the guide below as a reference, but you would also need to dump the database on your current server and import it properly on the new server. See our [Backing up PostgreSQL](maintenance-postgres.md#backing-up-postgresql) docs for help with PostgreSQL backup/restore.
 # Migrating to new server
--- a/docs/maintenance-postgres.md
+++ b/docs/maintenance-postgres.md
@ -87,6 +87,8 @@ This playbook can upgrade your existing Postgres setup with the following comman
 just run-tags upgrade-postgres
 ```
 **Warning: If you're using Borg Backup keep in mind that there is no official Postgres 16 support yet.**
 **The old Postgres data directory is backed up** automatically, by renaming it to `/matrix/postgres/data-auto-upgrade-backup`.
 To rename to a different path, pass some extra flags to the command above, like this: `--extra-vars="postgres_auto_upgrade_backup_data_path=/another/disk/matrix-postgres-before-upgrade"`
@ -111,7 +113,7 @@ You can manually influence some of the tuning variables . These parameters (vari
 Most users should be fine with the automatically-done tuning. However, you may wish to:
- **adjust the automatically-determined tuning parameters manually**: change the values for the tuning variables defined in the Postgres role's [default configuration file](https://github.com/devture/com.devture.ansible.role.postgres/blob/main/defaults/main.yml) (see `devture_postgres_max_connections`, `devture_postgres_data_storage` etc). These variables are ultimately passed to Postgres via a `devture_postgres_postgres_process_extra_arguments_auto` variable
+- **adjust the automatically-deterimned tuning parameters manually**: change the values for the tuning variables defined in the Postgres role's [default configuration file](https://github.com/devture/com.devture.ansible.role.postgres/blob/main/defaults/main.yml) (see `devture_postgres_max_connections`, `devture_postgres_data_storage` etc). These variables are ultimately passed to Postgres via a `devture_postgres_postgres_process_extra_arguments_auto` variable
 - **turn automatically-performed tuning off**: override it like this: `devture_postgres_postgres_process_extra_arguments_auto: []`
--- a/docs/maintenance-synapse.md
+++ b/docs/maintenance-synapse.md
@ -74,32 +74,8 @@ Synapse's presence feature which tracks which users are online and which are off
 If you have enough compute resources (CPU & RAM), you can make Synapse better use of them by [enabling load-balancing with workers](configuring-playbook-synapse.md#load-balancing-with-workers).
-[Tuning your PostgreSQL database](maintenance-postgres.md#tuning-postgresql) could also improve Synapse performance. The playbook tunes the integrated Postgres database automatically, but based on your needs you may wish to adjust tuning variables manually. If you're using an [external Postgres database](configuring-playbook-external-postgres.md), you will also need to tune Postgres manually.
+Tuning Synapse's cache factor can help reduce RAM usage. Use the variable `matrix_synapse_caches_global_factor` to set the cache factor.
-### Tuning caches and cache autotuning
+[Tuning your PostgreSQL database](maintenance-postgres.md#tuning-postgresql) could also improve Synapse performance. The playbook tunes the integrated Postgres database automatically, but based on your needs you may wish to adjust tuning variables manually. If you're using an [external Postgres database](configuring-playbook-external-postgres.md), you will aslo need to tune Postgres manually.
 Tuning Synapse's cache factor is useful for performance increases but also as part of controlling Synapse's memory use. Use the variable `matrix_synapse_caches_global_factor` to set the cache factor as part of this process.
 **The playbook defaults the global cache factor to a large value** (e.g. `10`). A smaller value (e.g. `0.5`) will decrease the amount used for caches, but will [not necessarily decrease RAM usage as a whole](https://github.com/matrix-org/synapse/issues/3939).
 Tuning the cache factor is useful only to a limited degree (as its crude to do in isolation) and therefore users who are tuning their cache factor should likely look into tuning autotune variables as well (see below).
 Cache autotuning is **enabled by default** and controlled 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`
 You can **learn more about cache-autotuning and the global cache factor settings** in the [Synapse's documentation on caches and associated values](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#caches-and-associated-values).
 To **disable cache auto-tuning**, unset all values:
 ```yml
 matrix_synapse_cache_autotuning_max_cache_memory_usage: ''
 matrix_synapse_cache_autotuning_target_cache_memory_usage: ''
 matrix_synapse_cache_autotuning_min_cache_ttl: ''
 ```
 Users who wish to lower Synapse's RAM footprint should look into lowering the global cache factor and tweaking the autotune variables (or disabling auto-tuning). If your cache factor is too low for a given auto tune setting your caches will not reach autotune thresholds and autotune won't be able to do its job. Therefore, when auto-tuning is enabled (which it is by default), it's recommended to have your cache factor be large.
 See also [How do I optimize this setup for a low-power server?](faq.md#how-do-i-optimize-this-setup-for-a-low-power-server).
--- a/docs/maintenance-upgrading-services.md
+++ b/docs/maintenance-upgrading-services.md
@ -6,13 +6,12 @@ If you want to be notified when new versions of Synapse are released, you should
 To upgrade services:
- update your playbook directory and all upstream Ansible roles (defined in the `requirements.yml` file) using:
+- update your playbook directory (`git pull`), so you'd obtain everything new we've done
  - either: `just update`
  - or: a combination of `git pull` and `just role` (or `make roles`)
 - take a look at [the changelog](../CHANGELOG.md) to see if there have been any backward-incompatible changes that you need to take care of
- re-run the [playbook setup](installing.md) and restart all services: `just install-all` or `just setup-all`
+- download the upstream Ansible roles used by the playbook by running `just roles`
 - re-run the [playbook setup](installing.md) and restart all services: `just setup-all`
 **Note**: major version upgrades to the internal PostgreSQL database are not done automatically. To upgrade it, refer to the [upgrading PostgreSQL guide](maintenance-postgres.md#upgrading-postgresql).
--- a/docs/prerequisites.md
+++ b/docs/prerequisites.md
@ -2,11 +2,11 @@
 To install Matrix services using this Ansible playbook, you need:
- (Recommended) An **x86** server ([What kind of server specs do I need?](faq.md#what-kind-of-server-specs-do-i-need)) running one of these operating systems that make use of [systemd](https://systemd.io/):
+- (Recommended) An **x86** server ([What kind of server specs do I need?](faq.md#what-kind-of-server-specs-do-i-need)) running one of these operating systems:
-  - **Archlinux**
+  - **CentOS** (7 only for now; [8 is not yet supported](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/300))
  - **CentOS**, **Rocky Linux**, **AlmaLinux**, or possibly other RHEL alternatives (although your mileage may vary)
  - **Debian** (10/Buster or newer)
-  - **Ubuntu** (18.04 or newer, although [20.04 may be problematic](ansible.md#supported-ansible-versions) if you run the Ansible playbook on it)
+  - **Ubuntu** (18.04 or newer, although [20.04 may be problematic](ansible.md#supported-ansible-versions))
  - **Archlinux**
 Generally, newer is better. We only strive to support released stable versions of distributions, not betas or pre-releases. This playbook can take over your whole server or co-exist with other services that you have there.
@ -26,7 +26,7 @@ If your distro runs within an [LXC container](https://linuxcontainers.org/), you
 - [`git`](https://git-scm.com/) is the recommended way to download the playbook to your computer. `git` may also be required on the server if you will be [self-building](self-building.md) components.
- [`just`](https://github.com/casey/just) for running `just roles`, `just update`, etc. (see [`justfile`](../justfile)), although you can also run these commands manually
+- [`just`](https://github.com/casey/just) for running `just roles`, etc. (see [`justfile`](../justfile)), although you can also run these commands manually
 - An HTTPS-capable web server at the base domain name (`<your-domain>`) which is capable of serving static files. Unless you decide to [Serve the base domain from the Matrix server](configuring-playbook-base-domain-serving.md) or alternatively, to use DNS SRV records for [Server Delegation](howto-server-delegation.md).
@ -35,12 +35,12 @@ If your distro runs within an [LXC container](https://linuxcontainers.org/), you
 - Some TCP/UDP ports open. This playbook (actually [Docker itself](https://docs.docker.com/network/iptables/)) configures the server's internal firewall for you. In most cases, you don't need to do anything special. But **if your server is running behind another firewall**, you'd need to open these ports:
  - `80/tcp`: HTTP webserver
-  - `443/tcp` and `443/udp`: HTTPS webserver
+  - `443/tcp`: HTTPS webserver
  - `3478/tcp`: TURN over TCP (used by Coturn)
  - `3478/udp`: TURN over UDP (used by Coturn)
  - `5349/tcp`: TURN over TCP (used by Coturn)
  - `5349/udp`: TURN over UDP (used by Coturn)
-  - `8448/tcp` and `8448/udp`: Matrix Federation API HTTPS webserver. In some cases, this **may necessary even with federation disabled**. Integration Servers (like Dimension) and Identity Servers (like ma1sd) may need to access `openid` APIs on the federation port.
+  - `8448/tcp`: Matrix Federation API HTTPS webserver. In some cases, this **may necessary even with federation disabled**. Integration Servers (like Dimension) and Identity Servers (like ma1sd) may need to access `openid` APIs on the federation port.
  - the range `49152-49172/udp`: TURN over UDP
  - potentially some other ports, depending on the additional (non-default) services that you enable in the **configuring the playbook** step (later on). Consult each service's documentation page in `docs/` for that.
--- a/docs/self-building.md
+++ b/docs/self-building.md
@ -40,7 +40,6 @@ Possibly outdated list of roles where self-building the Docker image is currentl
 - `matrix-bot-matrix-reminder-bot`
 - `matrix-bot-maubot`
 - `matrix-email2matrix`
 - `matrix-pantalaimon`
 Adding self-building support to other roles is welcome. Feel free to contribute!
--- a/examples/reverse-proxies/apache/matrix-domain.conf
+++ b/examples/reverse-proxies/apache/matrix-domain.conf
@ -29,7 +29,7 @@
 	RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
 	AllowEncodedSlashes NoDecode
-	ProxyPass / http://127.0.0.1:81/ retry=0 nocanon
+	ProxyPass / http://127.0.0.1:81 retry=0 nocanon
 	ProxyPassReverse / http://127.0.0.1:81/
 	ErrorLog ${APACHE_LOG_DIR}/matrix.DOMAIN-error.log
--- a/examples/reverse-proxies/nginx-proxy-manager/README.md
+++ b/examples/reverse-proxies/nginx-proxy-manager/README.md
@ -1,63 +0,0 @@
 # Nginx Proxy Manager fronting the playbook's integrated Traefik reverse-proxy
 Similar to standard nginx, [Nginx Proxy Manager](https://nginxproxymanager.com/) provides nginx capabilities but inside a pre-built Docker container. With the ability for managing proxy hosts and automatic SSL certificates via a simple web interface.
 This page summarizes how to use Nginx Proxy Manager (NPM) to front the integrated [Traefik](https://traefik.io/) reverse-proxy webserver.
 ## Prerequisite configuration
 To get started, first follow the [front the integrated reverse-proxy webserver with another reverse-proxy](../../../docs/configuring-playbook-own-webserver.md#fronting-the-integrated-reverse-proxy-webserver-with-another-reverse-proxy) instructions and update your playbook's configuration (`inventory/host_vars/matrix.<your-domain>/vars.yml`).
 If Matrix federation is enabled, then you will need to make changes to [NPM's Docker configuration](https://nginxproxymanager.com/guide/#quick-setup). By default NPM already exposes ports `80` and `443`, but you would also need to **additionally expose the Matrix Federation port** (as it appears on the public side): `8448`.
 ## Using Nginx Proxy Manager
 You'll need to create two proxy hosts in NPM for matrix web and federation traffic.
 Open the 'Proxy Hosts' page in the NPM web interface and select `Add Proxy Host`, the first being for matrix web traffic. Apply the proxys configuration like this:
 ```md
 # Details
 # Matrix web proxy config
 Domain Names: matrix.DOMAIN
 Scheme: http
 Forward Hostname/IP: IP-ADDRESS-OF-YOUR-MATRIX
 Forward Port: 81
 # SSL
 # Either 'Request a new certificate' or select an existing one
 SSL Certificate: matrix.DOMAIN or *.DOMAIN
 Force SSL: true
 HTTP/2 Support: true
 # Advanced
 Custom Nginx Configuration:
 	client_max_body_size 50M;
 ```
 Again, under the 'Proxy Hosts' page select `Add Proxy Host`, this time for your federation traffic. Apply the proxys configuration like this:
 ```md
 # Details
 # Matrix Federation proxy config
 Domain Names: matrix.DOMAIN:8448
 Scheme: http
 Forward Hostname/IP: IP-ADDRESS-OF-YOUR-MATRIX
 Forward Port: 8449
 # SSL
 # Either 'Request a new certificate' or select an existing one
 SSL Certificate: matrix.DOMAIN or *.DOMAIN
 Force SSL: true
 HTTP/2 Support: true
 # Advanced
 # Allows NPM to listen on the federation port
 Custom Nginx Configuration:
 	listen 8448 ssl http2;
 	client_max_body_size 50M;
 ```
 Also note, NPM would need to be configured for whatever other services you are using. For example, you would need to create additional proxy hosts for `element.DOMAIN` or `jitsi.DOMAIN`, which would use the forwarding port `81`.
--- a/examples/reverse-proxies/nginx/matrix.conf
+++ b/examples/reverse-proxies/nginx/matrix.conf
@ -1,14 +1,6 @@
 server {
-    # TODO: once per IP and port you should add `reuseport`, if you don't have that in any other nginx config file, add it here by uncommenting the lines below and commenting the one after with `quic` but without `reuseport`
+    listen 443 ssl http2;
-    #listen 443 quic reuseport;
+    listen [::]:443 ssl http2;
    listen 443 quic;
    listen 443 ssl;
 	# TODO: if you replaced the line above for port 443 and IPv4, you probably want to do the same for port 443 IPv6 by switching the two lines below
 	#listen [::]:443 quic reuseport;
    listen [::]:443 quic;
    listen [::]:443 ssl;
    http2 on;
    http3 on;
    # TODO: add/remove services and their subdomains if you use/don't use them
    # this example is using hosting something on the base domain and an element web client, so example.com and element.example.com are listed in addition to matrix.example.com
@ -32,9 +24,6 @@ server {
        # Nginx by default only allows file uploads up to 1M in size
        # Increase client_max_body_size to match max_upload_size defined in homeserver.yaml
        client_max_body_size 50M;
        # required for browsers to direct them to quic port
        add_header Alt-Svc 'h3=":443"; ma=86400';
    }
    # TODO: adapt the path to your ssl certificate for the domains listed on server_name
@ -48,16 +37,8 @@ server {
 # settings for matrix federation
 server {
    # For the federation port
-    # TODO: once per IP and port you should add `reuseport`, if you don't have that in any other nginx config file, add it here by uncommenting the lines below and commenting the one after with `quic` but without `reuseport`
+    listen 8448 ssl http2 default_server;
-    #listen 8448 quic reuseport;
+    listen [::]:8448 ssl http2 default_server;
    listen 8448 quic;
    listen 8448 ssl default_server;
    # TODO: if you replaced the line above for port 8448 and IPv4, you probably want to do the same for port 8448 IPv6 by switching the two lines below
    #listen [::]:8448 quic reuseport;
    listen [::]:8448 quic;
    listen [::]:8448 ssl default_server;
    http2 on;
    http3 on;
    server_name matrix.example.com;
@ -73,9 +54,6 @@ server {
        # Nginx by default only allows file uploads up to 1M in size
        # Increase client_max_body_size to match max_upload_size defined in homeserver.yaml
        client_max_body_size 50M;
 		# required for browsers to direct them to quic port
        add_header Alt-Svc 'h3=":8448"; ma=86400';
    }
    # TODO: adapt the path to your ssl certificate for the domains listed on server_name
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
--- a/flake.lock
+++ b/flake.lock
@ -1,60 +0,0 @@
 {
  "nodes": {
    "flake-utils": {
      "inputs": {
        "systems": "systems"
      },
      "locked": {
        "lastModified": 1710146030,
        "narHash": "sha256-SZ5L6eA7HJ/nmkzGG7/ISclqe6oZdOZTNoesiInkXPQ=",
        "owner": "numtide",
        "repo": "flake-utils",
        "rev": "b1d9ab70662946ef0850d488da1c9019f3a9752a",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "flake-utils",
        "type": "github"
      }
    },
    "nixpkgs": {
      "locked": {
        "lastModified": 1712578459,
        "narHash": "sha256-r+rjtYIdwV7mEqFwbvaS7dZSH+3xNW9loR3Rh9C0ifI=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "b1a486be09c354e25a18689eb21425e43892e38c",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "flake-utils": "flake-utils",
        "nixpkgs": "nixpkgs"
      }
    },
    "systems": {
      "locked": {
        "lastModified": 1681028828,
        "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
        "owner": "nix-systems",
        "repo": "default",
        "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
        "type": "github"
      },
      "original": {
        "owner": "nix-systems",
        "repo": "default",
        "type": "github"
      }
    }
  },
  "root": "root",
  "version": 7
 }
--- a/flake.nix
+++ b/flake.nix
@ -1,30 +1,19 @@
 {
-  inputs = {
+  inputs.nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
-    nixpkgs.url = "github:NixOS/nixpkgs";
+
-    flake-utils.url = "github:numtide/flake-utils";
+  outputs = { self, nixpkgs, ... }:
-  };
+    let
-  outputs = {
+      pkgs = import nixpkgs { system = "x86_64-linux"; };
    self,
    nixpkgs,
    flake-utils,
  }:
    flake-utils.lib.eachDefaultSystem
    (
      system: let
        pkgs = import nixpkgs {
          inherit system;
        };
    in
-        with pkgs; {
+    {
-          devShells.default = mkShell {
+      devShell.x86_64-linux = pkgs.mkShell {
-            buildInputs = [
+        buildInputs = with pkgs; [
          just
-              ansible
+          python311Packages.ansible-core
          python311Packages.passlib
        ];
-            shellHook = ''
+        LC_ALL = "C.UTF-8";
-              echo "$(ansible --version)"
+        LC_CTYPE = "C.UTF-8";
-            '';
+      };
    };
        }
    );
 }
--- a/group_vars/matrix_servers
+++ b/group_vars/matrix_servers
--- a/27
+++ b/27
@ -5,7 +5,6 @@ default:
 # Pulls external Ansible roles
 roles:
    #!/usr/bin/env sh
    echo "[NOTE] This command just updates the roles, but if you want to update everything at once (playbook, roles, etc.) - use 'just update'"
    if [ -x "$(command -v agru)" ]; then
    	agru
    else
@ -13,25 +12,9 @@ roles:
    	ansible-galaxy install -r requirements.yml -p roles/galaxy/ --force
    fi
-# Updates the playbook and installs the necessary Ansible roles pinned in requirements.yml. If a -u flag is passed, also updates the requirements.yml file with new role versions (if available)
+# Updates requirements.yml if there are any new tags available. Requires agru
-update *flags: update-playbook-only
+update:
-    #!/usr/bin/env sh
+    @agru -u
    if [ -x "$(command -v agru)" ]; then
        echo {{ if flags == "" { "Installing roles pinned in requirements.yml..." } else if flags == "-u" { "Updating roles and pinning new versions in requirements.yml..." } else { "Unknown flags passed" } }}
        agru {{ flags }}
    else
        echo "[NOTE] You are using the standard ansible-galaxy tool to install roles, which is slow and lacks other features. We recommend installing the 'agru' tool to speed up the process: https://github.com/etkecc/agru#where-to-get"
        echo "Installing roles..."
        rm -rf roles/galaxy
        ansible-galaxy install -r requirements.yml -p roles/galaxy/ --force
    fi
 # Updates the playbook without installing/updating Ansible roles
 update-playbook-only:
    @echo "Updating playbook..."
    @git stash -q
    @git pull -q
    @-git stash pop -q
 # Runs ansible-lint against all roles in the playbook
 lint:
@ -75,7 +58,3 @@ stop-all *extra_args: (run-tags "stop-all" extra_args)
 # Stops a specific service group
 stop-group group *extra_args:
    @just --justfile {{ justfile() }} run-tags stop-group --extra-vars="group={{ group }}" {{ extra_args }}
 # Rebuilds the mautrix-meta-instagram Ansible role using the mautrix-meta-messenger role as a source
 rebuild-mautrix-meta-instagram:
    /bin/bash {{ justfile_directory() }}/bin/rebuild-mautrix-meta-instagram.sh {{ justfile_directory() }}/roles/custom
--- a/requirements.yml
+++ b/requirements.yml
@ -3,38 +3,35 @@
 - src: git+https://github.com/mother-of-all-self-hosting/ansible-role-aux.git
  version: v1.0.0-3
  name: auxiliary
- src: git+https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg.git
+- src: git+https://gitlab.com/etke.cc/roles/backup_borg.git
-  version: v1.2.8-1.8.13-0
+  version: v1.2.7-1.8.6-0
  name: backup_borg
 - src: git+https://github.com/devture/com.devture.ansible.role.container_socket_proxy.git
-  version: v0.2.0-0
+  version: v0.1.1-3
  name: container_socket_proxy
 - src: git+https://github.com/geerlingguy/ansible-role-docker
-  version: 7.4.1
+  version: 7.0.2
  name: docker
 - src: git+https://github.com/devture/com.devture.ansible.role.docker_sdk_for_python.git
  version: 129c8590e106b83e6f4c259649a613c6279e937a
  name: docker_sdk_for_python
- src: git+https://github.com/mother-of-all-self-hosting/ansible-role-etherpad.git
+- src: git+https://gitlab.com/etke.cc/roles/etherpad.git
-  version: v2.2.2-0
+  version: v1.9.6-0
  name: etherpad
 - src: git+https://github.com/mother-of-all-self-hosting/ansible-role-exim-relay.git
-  version: v4.98-r0-1-0
+  version: v4.97-r0-0-1
  name: exim_relay
- src: git+https://github.com/mother-of-all-self-hosting/ansible-role-grafana.git
+- src: git+https://gitlab.com/etke.cc/roles/grafana.git
-  version: v11.1.4-0
+  version: v10.2.3-0
  name: grafana
 - src: git+https://github.com/mother-of-all-self-hosting/ansible-role-jitsi.git
-  version: v9646-0
+  version: v9111-1
  name: jitsi
- src: git+https://github.com/mother-of-all-self-hosting/ansible-role-keydb.git
+- src: git+https://gitlab.com/etke.cc/roles/ntfy.git
-  version: v6.3.4-2
+  version: v2.8.0-1
  name: keydb
 - src: git+https://github.com/mother-of-all-self-hosting/ansible-role-ntfy.git
  version: v2.10.0-1
  name: ntfy
 - src: git+https://github.com/devture/com.devture.ansible.role.playbook_help.git
-  version: 201c939eed363de269a83ba29784fc3244846048
+  version: c1f40e82b4d6b072b6f0e885239322bdaaaf554f
  name: playbook_help
 - src: git+https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages.git
  version: 9b4b088c62b528b73a9a7c93d3109b091dd42ec6
@ -43,35 +40,35 @@
  version: ff2fd42e1c1a9e28e3312bbd725395f9c2fc7f16
  name: playbook_state_preserver
 - src: git+https://github.com/devture/com.devture.ansible.role.postgres.git
-  version: v16.3-2
+  version: v16.1-4
  name: postgres
 - src: git+https://github.com/devture/com.devture.ansible.role.postgres_backup.git
-  version: 8c3585fb4857dbac026b2974bb6525289240effb
+  version: 7eadc992ca952fc29bf3fab5aa6335fa82ff01e5
  name: postgres_backup
 - src: git+https://github.com/mother-of-all-self-hosting/ansible-role-prometheus.git
-  version: v2.54.1-0
+  version: v2.49.1-0
  name: prometheus
 - src: git+https://github.com/mother-of-all-self-hosting/ansible-role-prometheus-node-exporter.git
-  version: v1.8.2-0
+  version: v1.7.0-2
  name: prometheus_node_exporter
 - src: git+https://github.com/mother-of-all-self-hosting/ansible-role-prometheus-postgres-exporter.git
-  version: v0.14.0-5
+  version: v0.14.0-3
  name: prometheus_postgres_exporter
- src: git+https://github.com/mother-of-all-self-hosting/ansible-role-redis.git
+- src: git+https://gitlab.com/etke.cc/roles/redis.git
-  version: v7.2.5-0
+  version: v7.2.3-2
  name: redis
 - src: git+https://github.com/devture/com.devture.ansible.role.systemd_docker_base.git
-  version: v1.2.0-0
+  version: v1.0.0-2
  name: systemd_docker_base
 - src: git+https://github.com/devture/com.devture.ansible.role.systemd_service_manager.git
-  version: v1.0.0-4
+  version: v1.0.0-3
  name: systemd_service_manager
 - src: git+https://github.com/devture/com.devture.ansible.role.timesync.git
  version: v1.0.0-0
  name: timesync
 - src: git+https://github.com/devture/com.devture.ansible.role.traefik.git
-  version: v3.1.2-1
+  version: v2.10.7-0
  name: traefik
 - src: git+https://github.com/devture/com.devture.ansible.role.traefik_certs_dumper.git
-  version: v2.8.3-4
+  version: v2.8.3-1
  name: traefik_certs_dumper
--- a/roles/custom/matrix-alertmanager-receiver/defaults/main.yml
+++ b/roles/custom/matrix-alertmanager-receiver/defaults/main.yml
@ -1,241 +0,0 @@
 ---
 # matrix-alertmanager-receiver is a service which receives webhook payloads from Prometheus' Alertmanager and forwards them to a Matrix room.
 # Project source code URL: https://github.com/metio/matrix-alertmanager-receiver
 matrix_alertmanager_receiver_enabled: true
 # renovate: datasource=docker depName=docker.io/metio/matrix-alertmanager-receiver
 matrix_alertmanager_receiver_version: 2024.8.28
 matrix_alertmanager_receiver_scheme: https
 # The hostname at which matrix-alertmanager-receiver is served.
 matrix_alertmanager_receiver_hostname: ''
 # The path at which matrix-alertmanager-receiver is served.
 # This value must either be `/` or not end with a slash (e.g. `/matrix-alertmanager-receiver`).
 matrix_alertmanager_receiver_path_prefix: /
 matrix_alertmanager_receiver_base_path: "{{ matrix_base_data_path }}/alertmanager-receiver"
 matrix_alertmanager_receiver_config_path: "{{ matrix_alertmanager_receiver_base_path }}/config"
 matrix_alertmanager_receiver_container_image_self_build: false
 matrix_alertmanager_receiver_container_image_self_build_repo: https://github.com/metio/matrix-alertmanager-receiver
 matrix_alertmanager_receiver_container_image_self_build_repo_version: "{{ 'main' if matrix_alertmanager_receiver_version == 'main' else matrix_alertmanager_receiver_version }}"
 matrix_alertmanager_receiver_container_src_path: "{{ matrix_alertmanager_receiver_base_path }}/container-src"
 matrix_alertmanager_receiver_container_image: "{{ matrix_alertmanager_receiver_container_image_name_prefix }}metio/matrix-alertmanager-receiver:{{ matrix_alertmanager_receiver_container_image_tag }}"
 matrix_alertmanager_receiver_container_image_name_prefix: "{{ 'localhost/' if matrix_alertmanager_receiver_container_image_self_build else matrix_alertmanager_receiver_container_image_registry_prefix }}"
 matrix_alertmanager_receiver_container_image_tag: "{{ matrix_alertmanager_receiver_version }}"
 matrix_alertmanager_receiver_container_image_force_pull: "{{ matrix_alertmanager_receiver_container_image.endswith(':main') }}"
 matrix_alertmanager_receiver_container_image_registry_prefix: docker.io/
 # The base container network. It will be auto-created by this role if it doesn't exist already.
 matrix_alertmanager_receiver_container_network: ''
 # A list of additional container networks that the container would be connected to.
 # The role does not create these networks, so make sure they already exist.
 matrix_alertmanager_receiver_container_additional_networks: "{{ matrix_alertmanager_receiver_container_additional_networks_default + matrix_alertmanager_receiver_container_additional_networks_auto + matrix_alertmanager_receiver_container_additional_networks_custom }}"
 matrix_alertmanager_receiver_container_additional_networks_default: []
 matrix_alertmanager_receiver_container_additional_networks_auto: []
 matrix_alertmanager_receiver_container_additional_networks_custom: []
 # Controls whether matrix-alertmanager-receiver metrics should be proxied (exposed) on `matrix.DOMAIN/metrics/matrix-alertmanager-receiver`
 matrix_alertmanager_receiver_metrics_proxying_enabled: false
 matrix_alertmanager_receiver_metrics_proxying_hostname: ''
 matrix_alertmanager_receiver_metrics_proxying_path: /metrics/matrix-alertmanager-receiver
 # matrix_alertmanager_receiver_container_labels_traefik_enabled controls whether labels to assist a Traefik reverse-proxy will be attached to the container.
 # See `../templates/labels.j2` for details.
 #
 # To inject your own other container labels, see `matrix_alertmanager_receiver_container_labels_additional_labels`.
 matrix_alertmanager_receiver_container_labels_traefik_enabled: true
 matrix_alertmanager_receiver_container_labels_traefik_docker_network: "{{ matrix_alertmanager_receiver_container_network }}"
 matrix_alertmanager_receiver_container_labels_traefik_hostname: "{{ matrix_alertmanager_receiver_hostname }}"
 # The path prefix must either be `/` or not end with a slash (e.g. `/matrix-alertmanager-receiver`).
 matrix_alertmanager_receiver_container_labels_traefik_path_prefix: "{{ matrix_alertmanager_receiver_path_prefix }}"
 matrix_alertmanager_receiver_container_labels_traefik_rule: "Host(`{{ matrix_alertmanager_receiver_container_labels_traefik_hostname }}`){% if matrix_alertmanager_receiver_container_labels_traefik_path_prefix != '/' %} && PathPrefix(`{{ matrix_alertmanager_receiver_container_labels_traefik_path_prefix }}`){% endif %}"
 matrix_alertmanager_receiver_container_labels_traefik_priority: 0
 matrix_alertmanager_receiver_container_labels_traefik_entrypoints: web-secure
 matrix_alertmanager_receiver_container_labels_traefik_tls: "{{ matrix_alertmanager_receiver_container_labels_traefik_entrypoints != 'web' }}"
 matrix_alertmanager_receiver_container_labels_traefik_tls_certResolver: default  # noqa var-naming
 # Controls whether labels will be added that expose metrics (see `matrix_alertmanager_receiver_metrics_proxying_enabled`) for matrix-alertmanager-receiver
 matrix_alertmanager_receiver_container_labels_public_metrics_enabled: "{{ matrix_alertmanager_receiver_metrics_enabled and matrix_alertmanager_receiver_metrics_proxying_enabled }}"
 matrix_alertmanager_receiver_container_labels_public_metrics_traefik_path: "{{ matrix_alertmanager_receiver_metrics_proxying_path }}"
 matrix_alertmanager_receiver_container_labels_public_metrics_traefik_rule: "Host(`{{ matrix_alertmanager_receiver_metrics_proxying_hostname }}`) && Path(`{{ matrix_alertmanager_receiver_container_labels_public_metrics_traefik_path }}`)"
 matrix_alertmanager_receiver_container_labels_public_metrics_traefik_priority: 0
 matrix_alertmanager_receiver_container_labels_public_metrics_traefik_entrypoints: "{{ matrix_alertmanager_receiver_container_labels_traefik_entrypoints }}"
 matrix_alertmanager_receiver_container_labels_public_metrics_traefik_tls: "{{ matrix_alertmanager_receiver_container_labels_public_metrics_traefik_entrypoints != 'web' }}"
 matrix_alertmanager_receiver_container_labels_public_metrics_traefik_tls_certResolver: "{{ matrix_alertmanager_receiver_container_labels_traefik_tls_certResolver }}"  # noqa var-naming
 matrix_alertmanager_receiver_container_labels_public_metrics_middleware_basic_auth_enabled: false
 # See: https://doc.traefik.io/traefik/middlewares/http/basicauth/#users
 matrix_alertmanager_receiver_container_labels_public_metrics_middleware_basic_auth_users: ''
 # matrix_alertmanager_receiver_container_labels_additional_labels contains a multiline string with additional labels to add to the container label file.
 # See `../templates/labels.j2` for details.
 #
 # Example:
 # matrix_alertmanager_receiver_container_labels_additional_labels: |
 #   my.label=1
 #   another.label="here"
 matrix_alertmanager_receiver_container_labels_additional_labels: ''
 # A list of extra arguments to pass to the container
 matrix_alertmanager_receiver_container_extra_arguments: []
 # Controls the `--log-level` argument passed to the container process.
 # Valid values: error, warn, info, debug
 matrix_alertmanager_receiver_container_process_argument_log_level: info
 # A list of extra arguments to pass to the container process.
 matrix_alertmanager_receiver_container_process_extra_arguments: []
 # List of systemd services that matrix-alertmanager-receiver-proxy.service depends on
 matrix_alertmanager_receiver_systemd_required_services_list: "{{ matrix_alertmanager_receiver_systemd_required_services_list_default + matrix_alertmanager_receiver_systemd_required_services_list_auto + matrix_alertmanager_receiver_systemd_required_services_list_custom }}"
 matrix_alertmanager_receiver_systemd_required_services_list_default: "{{ [devture_systemd_docker_base_docker_service_name] if devture_systemd_docker_base_docker_service_name else [] }}"
 matrix_alertmanager_receiver_systemd_required_services_list_auto: []
 matrix_alertmanager_receiver_systemd_required_services_list_custom: []
 # List of systemd services that matrix-alertmanager-receiver-proxy.service wants
 matrix_alertmanager_receiver_systemd_wanted_services_list: []
 # Controls the `http.port` configuration setting.
 matrix_alertmanager_receiver_config_http_port: 12345
 # Controls the `http.alerts-path-prefix` configuration setting.
 matrix_alertmanager_receiver_config_http_alerts_path_prefix: /alerts
 # Controls the `http.metrics-enabled` configuration setting.
 matrix_alertmanager_receiver_config_http_metrics_enabled: false
 # Controls the `http.metrics-path` configuration setting.
 matrix_alertmanager_receiver_config_http_metrics_path: /metrics
 # Controls the `matrix.homeserver-url` configuration setting.
 matrix_alertmanager_receiver_config_matrix_homeserver_url: ''
 # Controls the `matrix.user-id` configuration setting.
 matrix_alertmanager_receiver_config_matrix_user_id: "@{{ matrix_alertmanager_receiver_config_matrix_user_id_localpart }}:{{ matrix_domain }}"
 matrix_alertmanager_receiver_config_matrix_user_id_localpart: "bot.alertmanager.receiver"
 # Controls the `matrix.access-token` configuration setting.
 matrix_alertmanager_receiver_config_matrix_access_token: ''
 # Controls the `matrix.room-mapping` configuration setting.
 #
 # Example:
 # matrix_alertmanager_receiver_config_matrix_room:
 #   simple-name: "!qohfwef7qwerf:example.com"
 #   another-name: "!bf3zfio3wbanw:example.com"
 matrix_alertmanager_receiver_config_matrix_room_mapping: {}
 # Controls the `templating.external-url-mapping` configuration setting.
 #
 # The key is the original value taken from the Alertmanager payload
 # The value is the mapped value which will be available as '.ExternalURL' in templates
 #
 # Example:
 # matrix_alertmanager_receiver_config_templating_external_url_mapping:
 #   "http://alertmanager:9093": https://alertmanager.example.com
 #   "http://alertmanager:9094": https://another.alertmanager.example.com
 matrix_alertmanager_receiver_config_templating_external_url_mapping: {}
 # Controls the `templating.generator-url-mapping` configuration setting.
 #
 # The key is the original value taken from the Alertmanager payload
 # The value is the mapped value which will be available as '.ExternalURL' in templates
 #
 # Example:
 # matrix_alertmanager_receiver_config_templating_generator_url_mapping:
 #   "http://prometheus:8080": https://prometheus.example.com
 #   "http://prometheus:8081": https://another.prometheus.example.com
 matrix_alertmanager_receiver_config_templating_generator_url_mapping: {}
 # Controls the `templating.computed-values` configuration setting.
 matrix_alertmanager_receiver_config_templating_computed_values: "{{ matrix_alertmanager_receiver_config_templating_computed_values_default + matrix_alertmanager_receiver_config_templating_computed_values_auto + matrix_alertmanager_receiver_config_templating_computed_values_custom }}"
 matrix_alertmanager_receiver_config_templating_computed_values_default:
  - values:  # always set 'color' to 'yellow'
      color: yellow
  - values:  # set 'color' to 'orange' when alert label 'severity' is 'warning'
      color: orange
    when-matching-labels:
      severity: warning
  - values:  # set 'color' to 'red' when alert label 'severity' is 'critical'
      color: red
    when-matching-labels:
      severity: critical
  - values:  # set 'color' to 'green' when alert status is 'resolved'
      color: green
    when-matching-status: resolved
 matrix_alertmanager_receiver_config_templating_computed_values_auto: []
 matrix_alertmanager_receiver_config_templating_computed_values_custom: []
 # Controls the `templating.firing-template` configuration setting.
 matrix_alertmanager_receiver_config_templating_firing_template: |-
  {% raw %}
  <p>
    <strong><font color="{{ .ComputedValues.color }}">{{ .Alert.Status | ToUpper }}</font></strong>
    {{ if .Alert.Labels.name }}
      {{ .Alert.Labels.name }}
    {{ else if .Alert.Labels.alertname }}
      {{ .Alert.Labels.alertname }}
    {{ end }}
    >>
    {{ if .Alert.Labels.severity }}
      {{ .Alert.Labels.severity | ToUpper }}:
    {{ end }}
    {{ if .Alert.Annotations.description }}
      {{ .Alert.Annotations.description }}
    {{ else if .Alert.Annotations.summary }}
      {{ .Alert.Annotations.summary }}
    {{ end }}
    >>
    {{ if .Alert.Annotations.runbook_url }}
      <a href="{{ .Alert.Annotations.runbook_url }}">Runbook</a> |
    {{ end }}
    {{ if .Alert.Annotations.dashboard }}
      <a href="{{ .Alert.Annotations.dashboard }}">Dashboard</a> |
    {{ end }}
    <a href="{{ .SilenceURL }}">Silence</a>
  </p>
  {% endraw %}
 # Controls the `templating.resolved-template` configuration setting.
 matrix_alertmanager_receiver_config_templating_resolved_template: |-
  {% raw %}
  <strong><font color="{{ .ComputedValues.color }}">{{ .Alert.Status | ToUpper }}</font></strong>
  {{ if .Alert.Labels.name }}
    {{ .Alert.Labels.name }}
  {{ else if .Alert.Labels.alertname }}
    {{ .Alert.Labels.alertname }}
  {{ end }}
  {% endraw %}
 # Default matrix-alertmanager-receiver configuration template which covers the generic use case.
 # You can customize it by controlling the various variables inside it.
 #
 # For a more advanced customization, you can extend the default (see `matrix_alertmanager_receiver_configuration_extension_yaml`)
 # or completely replace this variable with your own template.
 matrix_alertmanager_receiver_configuration_yaml: "{{ lookup('template', 'templates/config.yml.j2') }}"
 matrix_alertmanager_receiver_configuration_extension_yaml: |
  # Your custom YAML configuration for matrix-alertmanager-receiver goes here.
  # This configuration extends the default starting configuration (`matrix_alertmanager_receiver_configuration_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_alertmanager_receiver_configuration_yaml`.
  #
  # Example configuration extension follows:
  #
  # http:
  #   address: ''
 matrix_alertmanager_receiver_configuration_extension: "{{ matrix_alertmanager_receiver_configuration_extension_yaml | from_yaml if matrix_alertmanager_receiver_configuration_extension_yaml | from_yaml is mapping else {} }}"
 # Holds the final matrix-alertmanager-receiver configuration (a combination of the default and its extension).
 # You most likely don't need to touch this variable. Instead, see `matrix_alertmanager_receiver_configuration_yaml`.
 matrix_alertmanager_receiver_configuration: "{{ matrix_alertmanager_receiver_configuration_yaml | from_yaml | combine(matrix_alertmanager_receiver_configuration_extension, recursive=True) }}"
--- a/roles/custom/matrix-alertmanager-receiver/tasks/install.yml
+++ b/roles/custom/matrix-alertmanager-receiver/tasks/install.yml
@ -1,80 +0,0 @@
 ---
 - name: Ensure matrix-alertmanager-receiver paths exist
  ansible.builtin.file:
    path: "{{ item.path }}"
    state: directory
    mode: 0750
    owner: "{{ matrix_user_username }}"
    group: "{{ matrix_user_groupname }}"
  with_items:
    - path: "{{ matrix_alertmanager_receiver_base_path }}"
      when: true
    - path: "{{ matrix_alertmanager_receiver_config_path }}"
      when: true
    - path: "{{ matrix_alertmanager_receiver_container_src_path }}"
      when: "{{ matrix_alertmanager_receiver_container_image_self_build }}"
  when: item.when | bool
 - name: Ensure matrix-alertmanager-receiver configuration installed
  ansible.builtin.copy:
    content: "{{ matrix_alertmanager_receiver_configuration | to_nice_yaml(indent=2, width=999999) }}"
    dest: "{{ matrix_alertmanager_receiver_config_path }}/config.yml"
    mode: 0644
    owner: "{{ matrix_user_username }}"
    group: "{{ matrix_user_groupname }}"
 - name: Ensure matrix-alertmanager-receiver support files installed
  ansible.builtin.template:
    src: "{{ role_path }}/templates/{{ item }}.j2"
    dest: "{{ matrix_alertmanager_receiver_base_path }}/{{ item }}"
    mode: 0640
    owner: "{{ matrix_user_username }}"
    group: "{{ matrix_user_groupname }}"
  with_items:
    - labels
 - name: Ensure matrix-alertmanager-receiver container image is pulled
  community.docker.docker_image:
    name: "{{ matrix_alertmanager_receiver_container_image }}"
    source: "{{ 'pull' if ansible_version.major > 2 or ansible_version.minor > 7 else omit }}"
    force_source: "{{ matrix_alertmanager_receiver_container_image_force_pull if ansible_version.major > 2 or ansible_version.minor >= 8 else omit }}"
    force: "{{ omit if ansible_version.major > 2 or ansible_version.minor >= 8 else matrix_alertmanager_receiver_container_image_force_pull }}"
  when: "not matrix_alertmanager_receiver_container_image_self_build | bool"
  register: result
  retries: "{{ devture_playbook_help_container_retries_count }}"
  delay: "{{ devture_playbook_help_container_retries_delay }}"
  until: result is not failed
 - when: matrix_alertmanager_receiver_container_image_self_build | bool
  block:
    - name: Ensure matrix-alertmanager-receiver repository is present on self-build
      ansible.builtin.git:
        repo: "{{ matrix_alertmanager_receiver_container_image_self_build_repo }}"
        version: "{{ matrix_alertmanager_receiver_container_image_self_build_repo_version }}"
        dest: "{{ matrix_alertmanager_receiver_container_src_path }}"
        force: "yes"
      become: true
      become_user: "{{ matrix_user_username }}"
      register: matrix_alertmanager_receiver_git_pull_results
    - name: Ensure matrix-alertmanager-receiver container image is built
      ansible.builtin.command:
        cmd: |-
          {{ devture_systemd_docker_base_host_command_docker }} buildx build
          --tag={{ matrix_alertmanager_receiver_container_image }}
          --file={{ matrix_alertmanager_receiver_container_src_path }}/contrib/Dockerfile
          {{ matrix_alertmanager_receiver_container_src_path }}
      changed_when: true
 - name: Ensure matrix-alertmanager-receiver container network is created
  community.general.docker_network:
    enable_ipv6: "{{ devture_systemd_docker_base_ipv6_enabled }}"
    name: "{{ matrix_alertmanager_receiver_container_network }}"
    driver: bridge
 - name: Ensure matrix-alertmanager-receiver.service installed
  ansible.builtin.template:
    src: "{{ role_path }}/templates/systemd/matrix-alertmanager-receiver.service.j2"
    dest: "{{ devture_systemd_docker_base_systemd_path }}/matrix-alertmanager-receiver.service"
    mode: 0644
--- a/roles/custom/matrix-alertmanager-receiver/tasks/main.yml
+++ b/roles/custom/matrix-alertmanager-receiver/tasks/main.yml
@ -1,20 +0,0 @@
 ---
 - tags:
    - setup-all
    - setup-alertmanager-receiver
    - install-all
    - install-alertmanager-receiver
  block:
    - when: matrix_alertmanager_receiver_enabled | bool
      ansible.builtin.include_tasks: "{{ role_path }}/tasks/validate_config.yml"
    - when: matrix_alertmanager_receiver_enabled | bool
      ansible.builtin.include_tasks: "{{ role_path }}/tasks/install.yml"
 - tags:
    - setup-all
    - setup-alertmanager-receiver
  block:
    - when: not matrix_alertmanager_receiver_enabled | bool
      ansible.builtin.include_tasks: "{{ role_path }}/tasks/uninstall.yml"
--- a/roles/custom/matrix-alertmanager-receiver/tasks/uninstall.yml
+++ b/roles/custom/matrix-alertmanager-receiver/tasks/uninstall.yml
@ -1,25 +0,0 @@
 ---
 - name: Check existence of matrix-alertmanager-receiver service
  ansible.builtin.stat:
    path: "{{ devture_systemd_docker_base_systemd_path }}/matrix-alertmanager-receiver.service"
  register: matrix_alertmanager_receiver_service_stat
 - when: matrix_alertmanager_receiver_service_stat.stat.exists | bool
  block:
    - name: Ensure matrix-alertmanager-receiver is stopped
      ansible.builtin.service:
        name: matrix-alertmanager-receiver
        state: stopped
        enabled: false
        daemon_reload: true
    - name: Ensure matrix-alertmanager-receiver.service doesn't exist
      ansible.builtin.file:
        path: "{{ devture_systemd_docker_base_systemd_path }}/matrix-alertmanager-receiver.service"
        state: absent
    - name: Ensure matrix-alertmanager-receiver paths don't exist
      ansible.builtin.file:
        path: "{{ matrix_alertmanager_receiver_base_path }}"
        state: absent
--- a/roles/custom/matrix-alertmanager-receiver/tasks/validate_config.yml
+++ b/roles/custom/matrix-alertmanager-receiver/tasks/validate_config.yml
@ -1,14 +0,0 @@
 ---
 - name: Fail if required matrix-alertmanager-receiver settings not defined
  ansible.builtin.fail:
    msg: >
      You need to define a required configuration setting (`{{ item.name }}`).
  when: "item.when | bool and vars[item.name] == ''"
  with_items:
    - {'name': 'matrix_alertmanager_receiver_hostname', when: true}
    - {'name': 'matrix_alertmanager_receiver_path_prefix', when: true}
    - {'name': 'matrix_alertmanager_receiver_config_matrix_homeserver_url', when: true}
    - {'name': 'matrix_alertmanager_receiver_config_matrix_access_token', when: true}
    - {'name': 'matrix_alertmanager_receiver_container_network', when: true}
    - {'name': 'matrix_alertmanager_receiver_metrics_proxying_hostname', when: "{{ matrix_alertmanager_receiver_metrics_proxying_enabled }}"}
    - {'name': 'matrix_alertmanager_receiver_metrics_proxying_path_prefix', when: "{{ matrix_alertmanager_receiver_metrics_proxying_enabled }}"}
--- a/roles/custom/matrix-alertmanager-receiver/templates/config.yml.j2
+++ b/roles/custom/matrix-alertmanager-receiver/templates/config.yml.j2
@ -1,37 +0,0 @@
 #jinja2: lstrip_blocks: "True"
 # configuration of the HTTP server
 http:
  address: 0.0.0.0 # bind address for this service. Can be left unspecified to bind on all interfaces
  port: {{ matrix_alertmanager_receiver_config_http_port | to_json }} # port used by this service
  alerts-path-prefix: {{ matrix_alertmanager_receiver_config_http_alerts_path_prefix | to_json }} # URL path for the webhook receiver called by an Alertmanager. Defaults to /alerts
  metrics-path: {{ matrix_alertmanager_receiver_config_http_metrics_path | to_json }} # URL path to collect metrics. Defaults to /metrics
  metrics-enabled: {{ matrix_alertmanager_receiver_config_http_metrics_enabled | to_json }} # Whether to enable metrics or not. Defaults to false
 # configuration for the Matrix connection
 matrix:
  homeserver-url: {{ matrix_alertmanager_receiver_config_matrix_homeserver_url | to_json }} # FQDN of the homeserver
  user-id: {{ matrix_alertmanager_receiver_config_matrix_user_id | to_json }} # ID of the user used by this service
  access-token: {{ matrix_alertmanager_receiver_config_matrix_access_token | to_json }} # Access token for the user ID
  # define short names for Matrix room ID
  room-mapping: {{ matrix_alertmanager_receiver_config_matrix_room_mapping | to_json }}
 # configuration of the templating features
 templating:
  # mapping of ExternalURL values
  # key is the original value taken from the Alertmanager payload
  # value is the mapped value which will be available as '.ExternalURL' in templates
  external-url-mapping: {{ matrix_alertmanager_receiver_config_templating_external_url_mapping | to_json }}
  # mapping of GeneratorURL values
  # key is the original value taken from the Alertmanager payload
  # value is the mapped value which will be available as '.GeneratorURL' in templates
  generator-url-mapping: {{ matrix_alertmanager_receiver_config_templating_generator_url_mapping | to_json }}
  # computation of arbitrary values based on matching alert annotations, labels, or status
  # values will be evaluated top to bottom, last entry wins
  computed-values: {{ matrix_alertmanager_receiver_config_templating_computed_values | to_json }}
  # template for alerts in status 'firing'
  firing-template: {{ matrix_alertmanager_receiver_config_templating_firing_template | to_json }}
  # template for alerts in status 'resolved', if not specified will use the firing-template
  resolved-template: {{ matrix_alertmanager_receiver_config_templating_resolved_template | to_json }}
--- a/roles/custom/matrix-alertmanager-receiver/templates/labels.j2
+++ b/roles/custom/matrix-alertmanager-receiver/templates/labels.j2
@ -1,69 +0,0 @@
 {% if matrix_alertmanager_receiver_container_labels_traefik_enabled %}
 traefik.enable=true
 {% if matrix_alertmanager_receiver_container_labels_traefik_docker_network %}
 traefik.docker.network={{ matrix_alertmanager_receiver_container_labels_traefik_docker_network }}
 {% endif %}
 traefik.http.services.matrix-alertmanager-receiver.loadbalancer.server.port={{ matrix_alertmanager_receiver_config_http_port }}
 {% set middlewares = [] %}
 {% if matrix_alertmanager_receiver_container_labels_traefik_path_prefix != '/' %}
 traefik.http.middlewares.matrix-alertmanager-receiver-slashless-redirect.redirectregex.regex=({{ matrix_alertmanager_receiver_container_labels_traefik_path_prefix | quote }})$
 traefik.http.middlewares.matrix-alertmanager-receiver-slashless-redirect.redirectregex.replacement=${1}/
 {% set middlewares = middlewares + ['matrix-alertmanager-receiver-slashless-redirect'] %}
 {% endif %}
 {% if matrix_alertmanager_receiver_container_labels_traefik_path_prefix != '/' %}
 traefik.http.middlewares.matrix-alertmanager-receiver-strip-prefix.stripprefix.prefixes={{ matrix_alertmanager_receiver_container_labels_traefik_path_prefix }}
 {% set middlewares = middlewares + ['matrix-alertmanager-receiver-strip-prefix'] %}
 {% endif %}
 traefik.http.routers.matrix-alertmanager-receiver.rule={{ matrix_alertmanager_receiver_container_labels_traefik_rule }}
 {% if matrix_alertmanager_receiver_container_labels_traefik_priority | int > 0 %}
 traefik.http.routers.matrix-alertmanager-receiver.priority={{ matrix_alertmanager_receiver_container_labels_traefik_priority }}
 {% endif %}
 traefik.http.routers.matrix-alertmanager-receiver.service=matrix-alertmanager-receiver
 {% if middlewares | length > 0 %}
 traefik.http.routers.matrix-alertmanager-receiver.middlewares={{ middlewares | join(',') }}
 {% endif %}
 traefik.http.routers.matrix-alertmanager-receiver.entrypoints={{ matrix_alertmanager_receiver_container_labels_traefik_entrypoints }}
 traefik.http.routers.matrix-alertmanager-receiver.tls={{ matrix_alertmanager_receiver_container_labels_traefik_tls | to_json }}
 {% if matrix_alertmanager_receiver_container_labels_traefik_tls %}
 traefik.http.routers.matrix-alertmanager-receiver.tls.certResolver={{ matrix_alertmanager_receiver_container_labels_traefik_tls_certResolver }}
 {% endif %}
 {% if matrix_alertmanager_receiver_container_labels_public_metrics_enabled %}
 {% set metrics_middlewares = [] %}
 {% if matrix_alertmanager_receiver_container_labels_public_metrics_middleware_basic_auth_enabled %}
 {% set metrics_middlewares = metrics_middlewares + ['matrix-alertmanager-receiver-metrics-basic-auth'] %}
 traefik.http.middlewares.matrix-alertmanager-receiver-metrics-basic-auth.basicauth.users={{ matrix_alertmanager_receiver_container_labels_public_metrics_middleware_basic_auth_users }}
 {% endif %}
 {% set metrics_middlewares = metrics_middlewares + ['matrix-alertmanager-receiver-metrics-replacepath'] %}
 traefik.http.middlewares.matrix-alertmanager-receiver-metrics-replacepath.replacepath.path={{ matrix_alertmanager_receiver_config_http_metrics_path }}
 traefik.http.routers.matrix-alertmanager-receiver-metrics.rule={{ matrix_alertmanager_receiver_container_labels_public_metrics_traefik_rule }}
 {% if metrics_middlewares | length > 0 %}
 traefik.http.routers.matrix-alertmanager-receiver-metrics.middlewares={{ metrics_middlewares | join(',') }}
 {% endif %}
 {% if matrix_alertmanager_receiver_container_labels_public_metrics_traefik_priority | int > 0 %}
 traefik.http.routers.matrix-alertmanager-receiver-metrics.priority={{ matrix_alertmanager_receiver_container_labels_public_metrics_traefik_priority }}
 {% endif %}
 traefik.http.routers.matrix-alertmanager-receiver-metrics.service=matrix-alertmanager-receiver
 traefik.http.routers.matrix-alertmanager-receiver-metrics.entrypoints={{ matrix_alertmanager_receiver_container_labels_public_metrics_traefik_entrypoints }}
 traefik.http.routers.matrix-alertmanager-receiver-metrics.tls={{ matrix_alertmanager_receiver_container_labels_public_metrics_traefik_tls | to_json }}
 {% if matrix_alertmanager_receiver_container_labels_public_metrics_traefik_tls %}
 traefik.http.routers.matrix-alertmanager-receiver-metrics.tls.certResolver={{ matrix_alertmanager_receiver_container_labels_public_metrics_traefik_tls_certResolver }}
 {% endif %}
 {% endif %}
 {% endif %}
 {{ matrix_alertmanager_receiver_container_labels_additional_labels }}
--- a/roles/custom/matrix-alertmanager-receiver/templates/systemd/matrix-alertmanager-receiver.service.j2
+++ b/roles/custom/matrix-alertmanager-receiver/templates/systemd/matrix-alertmanager-receiver.service.j2
@ -1,50 +0,0 @@
 #jinja2: lstrip_blocks: "True"
 [Unit]
 Description=matrix-alertmanager-receiver
 {% for service in matrix_alertmanager_receiver_systemd_required_services_list %}
 Requires={{ service }}
 After={{ service }}
 {% endfor %}
 {% for service in matrix_alertmanager_receiver_systemd_wanted_services_list %}
 Wants={{ service }}
 {% endfor %}
 DefaultDependencies=no
 [Service]
 Type=simple
 Environment="HOME={{ devture_systemd_docker_base_systemd_unit_home_path }}"
 ExecStartPre=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} stop --time={{ devture_systemd_docker_base_container_stop_grace_time_seconds }} matrix-alertmanager-receiver 2>/dev/null || true'
 ExecStartPre=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} rm matrix-alertmanager-receiver 2>/dev/null || true'
 ExecStartPre={{ devture_systemd_docker_base_host_command_docker }} create \
 			--rm \
 			--name=matrix-alertmanager-receiver \
 			--log-driver=none \
 			--user={{ matrix_user_uid }}:{{ matrix_user_gid }} \
 			--cap-drop=ALL \
 			--read-only \
 			--network={{ matrix_alertmanager_receiver_container_network }} \
 			--mount type=bind,src={{ matrix_alertmanager_receiver_config_path }},dst=/config,ro \
 			--label-file={{ matrix_alertmanager_receiver_base_path }}/labels \
 			{% for arg in matrix_alertmanager_receiver_container_extra_arguments %}
 			{{ arg }} \
 			{% endfor %}
 			{{ matrix_alertmanager_receiver_container_image }} \
 			--config-path=/config/config.yml {{ matrix_alertmanager_receiver_container_process_extra_arguments | join(' ') }} \
 			--log-level={{ matrix_alertmanager_receiver_container_process_argument_log_level }}
 {% for network in matrix_alertmanager_receiver_container_additional_networks %}
 ExecStartPre={{ devture_systemd_docker_base_host_command_docker }} network connect {{ network }} matrix-alertmanager-receiver
 {% endfor %}
 ExecStart={{ devture_systemd_docker_base_host_command_docker }} start --attach matrix-alertmanager-receiver
 ExecStop=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} stop --time={{ devture_systemd_docker_base_container_stop_grace_time_seconds }} matrix-alertmanager-receiver 2>/dev/null || true'
 ExecStop=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} rm matrix-alertmanager-receiver 2>/dev/null || true'
 Restart=always
 RestartSec=30
 SyslogIdentifier=matrix-alertmanager-receiver
 [Install]
 WantedBy=multi-user.target
--- a/roles/custom/matrix-appservice-double-puppet/defaults/main.yml
+++ b/roles/custom/matrix-appservice-double-puppet/defaults/main.yml
@ -1,40 +0,0 @@
 ---
 matrix_appservice_double_puppet_enabled: true
 matrix_appservice_double_puppet_base_path: "{{ matrix_base_data_path }}/appservice-double-puppet"
 matrix_appservice_double_puppet_config_path: "{{ matrix_appservice_double_puppet_base_path }}/config"
 matrix_appservice_double_puppet_registration_id: double-puppet
 matrix_appservice_double_puppet_registration_url: ~
 matrix_appservice_double_puppet_registration_as_token: ''
 matrix_appservice_double_puppet_registration_hs_token: ''
 matrix_appservice_double_puppet_registration_sender_localpart: appservice-double-puppet
 matrix_appservice_double_puppet_registration_namespace_user_regex: "{{ '@.*:' + (matrix_domain | regex_escape) }}"
 # Default matrix-appservice-double-puppet registration configuration template which covers the generic use case.
 # You can customize it by controlling the various variables inside it.
 #
 # For a more advanced customization, you can extend the default (see `matrix_appservice_double_puppet_registration_configuration_extension_yaml`)
 # or completely replace this variable with your own template.
 matrix_appservice_double_puppet_registration_configuration_yaml: "{{ lookup('template', 'templates/registration.yaml.j2') }}"
 matrix_appservice_double_puppet_registration_configuration_extension_yaml: |
  # Your custom YAML configuration for matrix-appservice-double-puppet goes here.
  # This configuration extends the default starting configuration (`matrix_appservice_double_puppet_registration_configuration_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_double_puppet_registration_configuration_yaml`.
  #
  # Example configuration extension follows:
  #
  # rate_limited: true
 matrix_appservice_double_puppet_registration_configuration_extension: "{{ matrix_appservice_double_puppet_registration_configuration_extension_yaml | from_yaml if matrix_appservice_double_puppet_registration_configuration_extension_yaml | from_yaml is mapping else {} }}"
 # Holds the final matrix-appservice-double-puppet configuration (a combination of the default and its extension).
 # You most likely don't need to touch this variable. Instead, see `matrix_appservice_double_puppet_registration_configuration_yaml`.
 matrix_appservice_double_puppet_registration_configuration: "{{ matrix_appservice_double_puppet_registration_configuration_yaml | from_yaml | combine(matrix_appservice_double_puppet_registration_configuration_extension, recursive=True) }}"
--- a/roles/custom/matrix-appservice-double-puppet/tasks/install.yml
+++ b/roles/custom/matrix-appservice-double-puppet/tasks/install.yml
@ -1,23 +0,0 @@
 ---
 - name: Ensure matrix-appservice-double-puppet paths exist
  ansible.builtin.file:
    path: "{{ item.path }}"
    state: directory
    mode: 0750
    owner: "{{ matrix_user_username }}"
    group: "{{ matrix_user_groupname }}"
  with_items:
    - path: "{{ matrix_appservice_double_puppet_base_path }}"
      when: true
    - path: "{{ matrix_appservice_double_puppet_config_path }}"
      when: true
  when: item.when | bool
 - name: Ensure matrix-appservice-double-puppet registration configuration installed
  ansible.builtin.copy:
    content: "{{ matrix_appservice_double_puppet_registration_configuration | to_nice_yaml(indent=2, width=999999) }}"
    dest: "{{ matrix_appservice_double_puppet_config_path }}/registration.yaml"
    mode: 0644
    owner: "{{ matrix_user_username }}"
    group: "{{ matrix_user_groupname }}"
--- a/roles/custom/matrix-appservice-double-puppet/tasks/main.yml
+++ b/roles/custom/matrix-appservice-double-puppet/tasks/main.yml
@ -1,20 +0,0 @@
 ---
 - tags:
    - setup-all
    - setup-appservice-double-puppet
    - install-all
    - install-appservice-double-puppet
  block:
    - when: matrix_appservice_double_puppet_enabled | bool
      ansible.builtin.include_tasks: "{{ role_path }}/tasks/validate_config.yml"
    - when: matrix_appservice_double_puppet_enabled | bool
      ansible.builtin.include_tasks: "{{ role_path }}/tasks/install.yml"
 - tags:
    - setup-all
    - setup-appservice-double-puppet
  block:
    - when: not matrix_appservice_double_puppet_enabled | bool
      ansible.builtin.include_tasks: "{{ role_path }}/tasks/uninstall.yml"
--- a/roles/custom/matrix-appservice-double-puppet/tasks/uninstall.yml
+++ b/roles/custom/matrix-appservice-double-puppet/tasks/uninstall.yml
@ -1,6 +0,0 @@
 ---
 - name: Ensure matrix-appservice-double-puppet paths don't exist
  ansible.builtin.file:
    path: "{{ matrix_appservice_double_puppet_base_path }}"
    state: absent
--- a/roles/custom/matrix-appservice-double-puppet/tasks/validate_config.yml
+++ b/roles/custom/matrix-appservice-double-puppet/tasks/validate_config.yml
@ -1,10 +0,0 @@
 ---
 - name: Fail if required matrix-appservice-double-puppet settings not defined
  ansible.builtin.fail:
    msg: >
      You need to define a required configuration setting (`{{ item.name }}`).
  when: "item.when | bool and vars[item.name] == ''"
  with_items:
    - {'name': 'matrix_appservice_double_puppet_registration_as_token', when: true}
    - {'name': 'matrix_appservice_double_puppet_registration_as_token', when: true}
    - {'name': 'matrix_appservice_double_puppet_registration_sender_localpart', when: true}
--- a/roles/custom/matrix-appservice-double-puppet/templates/registration.yaml.j2
+++ b/roles/custom/matrix-appservice-double-puppet/templates/registration.yaml.j2
@ -1,21 +0,0 @@
 # The ID doesn't really matter, put whatever you want.
 id: {{ matrix_appservice_double_puppet_registration_id | to_json }}
 # The URL is intentionally left empty (null), as the homeserver shouldn't
 # push events anywhere for this extra appservice. If you use a
 # non-spec-compliant server, you may need to put some fake URL here.
 url: {{ matrix_appservice_double_puppet_registration_url | to_json }}
 # Generate random strings for these three fields. Only the as_token really
 # matters, hs_token is never used because there's no url, and the default
 # user (sender_localpart) is never used either.
 as_token: {{ matrix_appservice_double_puppet_registration_as_token | to_json }}
 hs_token: {{ matrix_appservice_double_puppet_registration_hs_token | to_json }}
 sender_localpart: {{ matrix_appservice_double_puppet_registration_sender_localpart | to_json}}
 # Bridges don't like ratelimiting. This should only apply when using the
 # as_token, normal user tokens will still be ratelimited.
 rate_limited: false
 namespaces:
  users:
  # Replace your\.domain with your server name (escape dots for regex)
  - regex: {{ matrix_appservice_double_puppet_registration_namespace_user_regex | to_json }}
    # This must be false so the appservice doesn't take over all users completely.
    exclusive: false
--- a/roles/custom/matrix-appservice-draupnir-for-all/defaults/main.yml
+++ b/roles/custom/matrix-appservice-draupnir-for-all/defaults/main.yml
@ -1,103 +0,0 @@
 ---
 # A moderation tool for Matrix
 # Project source code URL: https://github.com/the-draupnir-project/Draupnir
 matrix_appservice_draupnir_for_all_enabled: true
 # renovate: datasource=docker depName=gnuxie/draupnir
 matrix_appservice_draupnir_for_all_version: "1.87.0"
 matrix_appservice_draupnir_for_all_container_image_self_build: false
 matrix_appservice_draupnir_for_all_container_image_self_build_repo: "https://github.com/the-draupnir-project/Draupnir.git"
 matrix_appservice_draupnir_for_all_docker_image: "{{ matrix_appservice_draupnir_for_all_docker_image_name_prefix }}gnuxie/draupnir:{{ matrix_appservice_draupnir_for_all_version }}"
 matrix_appservice_draupnir_for_all_docker_image_name_prefix: "{{ 'localhost/' if matrix_appservice_draupnir_for_all_container_image_self_build else matrix_container_global_registry_prefix }}"
 matrix_appservice_draupnir_for_all_docker_image_force_pull: "{{ matrix_appservice_draupnir_for_all_docker_image.endswith(':latest') }}"
 matrix_appservice_draupnir_for_all_base_path: "{{ matrix_base_data_path }}/draupnir-for-all"
 matrix_appservice_draupnir_for_all_config_path: "{{ matrix_appservice_draupnir_for_all_base_path }}/config"
 matrix_appservice_draupnir_for_all_data_path: "{{ matrix_appservice_draupnir_for_all_base_path }}/data"
 matrix_appservice_draupnir_for_all_docker_src_files_path: "{{ matrix_appservice_draupnir_for_all_base_path }}/docker-src"
 matrix_appservice_draupnir_for_all_container_network: ""
 matrix_appservice_draupnir_for_all_container_additional_networks: "{{ matrix_appservice_draupnir_for_all_container_additional_networks_auto + matrix_appservice_draupnir_for_all_container_additional_networks_custom }}"
 matrix_appservice_draupnir_for_all_container_additional_networks_auto: []
 matrix_appservice_draupnir_for_all_container_additional_networks_custom: []
 # A list of extra arguments to pass to the container
 matrix_appservice_draupnir_for_all_container_extra_arguments: []
 # List of systemd services that matrix-bot-draupnir.service depends on
 matrix_appservice_draupnir_for_all_systemd_required_services_list: "{{ matrix_appservice_draupnir_for_all_systemd_required_services_list_default + matrix_appservice_draupnir_for_all_systemd_required_services_list_auto + matrix_appservice_draupnir_for_all_systemd_required_services_list_custom }}"
 matrix_appservice_draupnir_for_all_systemd_required_services_list_default: "{{ [devture_systemd_docker_base_docker_service_name] if devture_systemd_docker_base_docker_service_name else [] }}"
 matrix_appservice_draupnir_for_all_systemd_required_services_list_auto: []
 matrix_appservice_draupnir_for_all_systemd_required_services_list_custom: []
 # List of systemd services that matrix-bot-draupnir.service wants
 matrix_appservice_draupnir_for_all_systemd_wanted_services_list: []
 # The room ID where people can use the bot. The bot has no access controls, so
 # anyone in this room can use the bot - secure your room!
 # This should be a room alias - not a matrix.to URL.
 # Note: draupnir is fairly verbose - expect a lot of messages from it.
 # This room is diffrent for Appservice Mode compared to normal mode.
 # In Appservice mode it provides functions like user management.
 matrix_appservice_draupnir_for_all_master_control_room_alias: ""
 # Placeholder Remenant of the fact that Cat belived Master Control Room to be separated from Access Control Policy List.
 # The alias of the Policy list used to control who can provision a bot for them selfs.
 # This should be a room alias - not a matrix.to URL.
 # matrix_appservice_draupnir_for_all_management_policy_list_alias: ""
 matrix_appservice_draupnir_for_all_database_username: matrix_appservice_draupnir_for_all
 matrix_appservice_draupnir_for_all_database_password: 'some-passsword'
 matrix_appservice_draupnir_for_all_database_hostname: ''
 matrix_appservice_draupnir_for_all_database_port: 5432
 matrix_appservice_draupnir_for_all_database_name: matrix_appservice_draupnir_for_all
 matrix_appservice_draupnir_for_all_database_sslmode: disable
 matrix_appservice_draupnir_for_all_appservice_port: "9001"
 matrix_appservice_draupnir_for_all_appservice_url: 'http://matrix-appservice-draupnir-for-all'
 matrix_appservice_draupnir_for_all_database_connection_string: 'postgresql://{{ matrix_appservice_draupnir_for_all_database_username }}:{{ matrix_appservice_draupnir_for_all_database_password }}@{{ matrix_appservice_draupnir_for_all_database_hostname }}:{{ matrix_appservice_draupnir_for_all_database_port }}/{{ matrix_appservice_draupnir_for_all_database_name }}?sslmode={{ matrix_appservice_draupnir_for_all_database_sslmode }}'
 matrix_appservice_draupnir_for_all_user_prefix: "draupnir_"
 matrix_appservice_draupnir_for_all_registration_yaml: |
  id: "draupnir-for-all"
  as_token: "{{ matrix_appservice_draupnir_for_all_appservice_token }}"
  hs_token: "{{ matrix_appservice_draupnir_for_all_homeserver_token }}"
  url: "{{ matrix_appservice_draupnir_for_all_appservice_url }}:{{ matrix_appservice_draupnir_for_all_appservice_port }}"
  sender_localpart: draupnir-main
  namespaces:
    users:
    - exclusive: true
      regex: '@{{ matrix_appservice_draupnir_for_all_user_prefix }}*'
  rate_limited: false
 matrix_appservice_draupnir_for_all_registration: "{{ matrix_appservice_draupnir_for_all_registration_yaml | from_yaml }}"
 matrix_appservice_draupnir_for_all_configuration_appservice: "{{ lookup('template', 'templates/production-appservice.yaml.j2') | from_yaml }}"
 # Default configuration template which covers the generic use case.
 # You can customize it by controlling the various variables inside it.
 #
 # For a more advanced customization, you can extend the default (see `matrix_appservice_draupnir_for_all_configuration_extension_yaml`)
 # or completely replace this variable with your own template.
 matrix_appservice_draupnir_for_all_configuration_yaml: "{{ lookup('template', 'templates/production-bots.yaml.j2') }}"
 matrix_appservice_draupnir_for_all_configuration_extension_yaml: |
  # Your custom YAML configuration goes here.
  # This configuration extends the default starting configuration (`matrix_appservice_draupnir_for_all_configuration_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_configuration_yaml`.
 matrix_appservice_draupnir_for_all_configuration_extension: "{{ matrix_appservice_draupnir_for_all_configuration_extension_yaml | from_yaml if matrix_appservice_draupnir_for_all_configuration_extension_yaml | from_yaml is mapping else {} }}"
 # Holds the final configuration (a combination of the default and its extension).
 # You most likely don't need to touch this variable. Instead, see `matrix_appservice_draupnir_for_all_configuration_yaml`.
 matrix_appservice_draupnir_for_all_configuration: "{{ matrix_appservice_draupnir_for_all_configuration_yaml | from_yaml | combine(matrix_appservice_draupnir_for_all_configuration_extension, recursive=True) }}"
--- a/roles/custom/matrix-appservice-draupnir-for-all/tasks/main.yml
+++ b/roles/custom/matrix-appservice-draupnir-for-all/tasks/main.yml
@ -1,20 +0,0 @@
 ---
 - tags:
    - setup-all
    - setup-appservice-draupnir-for-all
    - install-all
    - install-appservice-draupnir-for-all
  block:
    - when: matrix_appservice_draupnir_for_all_enabled | bool
      ansible.builtin.include_tasks: "{{ role_path }}/tasks/validate_config.yml"
    - when: matrix_appservice_draupnir_for_all_enabled | bool
      ansible.builtin.include_tasks: "{{ role_path }}/tasks/setup_install.yml"
 - tags:
    - setup-all
    - setup-appservice-draupnir-for-all
  block:
    - when: not matrix_appservice_draupnir_for_all_enabled | bool
      ansible.builtin.include_tasks: "{{ role_path }}/tasks/setup_uninstall.yml"
--- a/roles/custom/matrix-appservice-draupnir-for-all/tasks/setup_install.yml
+++ b/roles/custom/matrix-appservice-draupnir-for-all/tasks/setup_install.yml
@ -1,96 +0,0 @@
 ---
 - ansible.builtin.set_fact:
    matrix_appservice_draupnir_for_all_requires_restart: false
 - name: Ensure matrix-appservice-draupnir-for-all paths exist
  ansible.builtin.file:
    path: "{{ item.path }}"
    state: directory
    mode: 0750
    owner: "{{ matrix_user_username }}"
    group: "{{ matrix_user_groupname }}"
  with_items:
    - {path: "{{ matrix_appservice_draupnir_for_all_base_path }}", when: true}
    - {path: "{{ matrix_appservice_draupnir_for_all_config_path }}", when: true}
    - {path: "{{ matrix_appservice_draupnir_for_all_data_path }}", when: true}
    - {path: "{{ matrix_appservice_draupnir_for_all_docker_src_files_path }}", when: "{{ matrix_appservice_draupnir_for_all_container_image_self_build }}"}
  when: "item.when | bool"
 - name: Ensure draupnir Docker image is pulled
  community.docker.docker_image:
    name: "{{ matrix_appservice_draupnir_for_all_docker_image }}"
    source: "{{ 'pull' if ansible_version.major > 2 or ansible_version.minor > 7 else omit }}"
    force_source: "{{ matrix_appservice_draupnir_for_all_docker_image_force_pull if ansible_version.major > 2 or ansible_version.minor >= 8 else omit }}"
    force: "{{ omit if ansible_version.major > 2 or ansible_version.minor >= 8 else matrix_appservice_draupnir_for_all_docker_image_force_pull }}"
  when: "not matrix_appservice_draupnir_for_all_container_image_self_build | bool"
  register: result
  retries: "{{ devture_playbook_help_container_retries_count }}"
  delay: "{{ devture_playbook_help_container_retries_delay }}"
  until: result is not failed
 - name: Ensure draupnir repository is present on self-build
  ansible.builtin.git:
    repo: "{{ matrix_appservice_draupnir_for_all_container_image_self_build_repo }}"
    dest: "{{ matrix_appservice_draupnir_for_all_docker_src_files_path }}"
    version: "{{ matrix_appservice_draupnir_for_all_docker_image.split(':')[1] }}"
    force: "yes"
  become: true
  become_user: "{{ matrix_user_username }}"
  register: matrix_appservice_draupnir_for_all_git_pull_results
  when: "matrix_appservice_draupnir_for_all_container_image_self_build | bool"
 - name: Ensure draupnir Docker image is built
  community.docker.docker_image:
    name: "{{ matrix_appservice_draupnir_for_all_docker_image }}"
    source: build
    force_source: "{{ matrix_appservice_draupnir_for_all_git_pull_results.changed }}"
    build:
      dockerfile: Dockerfile
      path: "{{ matrix_appservice_draupnir_for_all_docker_src_files_path }}"
      pull: true
  when: "matrix_appservice_draupnir_for_all_container_image_self_build | bool"
 - name: Ensure matrix-appservice-draupnir-for-all appservice config installed
  ansible.builtin.copy:
    content: "{{ matrix_appservice_draupnir_for_all_configuration_appservice | to_nice_yaml(indent=2, width=999999) }}"
    dest: "{{ matrix_appservice_draupnir_for_all_config_path }}/production-appservice.yaml"
    mode: 0644
    owner: "{{ matrix_user_username }}"
    group: "{{ matrix_user_groupname }}"
 - name: Ensure matrix-appservice-draupnir-for-all bot config installed
  ansible.builtin.copy:
    content: "{{ matrix_appservice_draupnir_for_all_configuration | to_nice_yaml(indent=2, width=999999) }}"
    dest: "{{ matrix_appservice_draupnir_for_all_config_path }}/production-bots.yaml"
    mode: 0644
    owner: "{{ matrix_user_username }}"
    group: "{{ matrix_user_groupname }}"
 - name: Ensure matrix-appservice-draupnir-for-all registration.yaml installed
  ansible.builtin.copy:
    content: "{{ matrix_appservice_draupnir_for_all_registration | to_nice_yaml(indent=2, width=999999) }}"
    dest: "{{ matrix_appservice_draupnir_for_all_config_path }}/draupnir-for-all-registration.yaml"
    mode: 0644
    owner: "{{ matrix_user_username }}"
    group: "{{ matrix_user_groupname }}"
 - name: Ensure matrix-appservice-draupnir-for-all container network is created
  community.general.docker_network:
    enable_ipv6: "{{ devture_systemd_docker_base_ipv6_enabled }}"
    name: "{{ matrix_appservice_draupnir_for_all_container_network }}"
    driver: bridge
 - name: Ensure matrix-appservice-draupnir-for-all.service installed
  ansible.builtin.template:
    src: "{{ role_path }}/templates/systemd/matrix-appservice-draupnir-for-all.service.j2"
    dest: "{{ devture_systemd_docker_base_systemd_path }}/matrix-appservice-draupnir-for-all.service"
    mode: 0644
  register: matrix_appservice_draupnir_for_all_systemd_service_result
 - name: Ensure matrix-appservice-draupnir-for-all.service restarted, if necessary
  ansible.builtin.service:
    name: "matrix-appservice-draupnir-for-all.service"
    state: restarted
    daemon_reload: true
  when: "matrix_appservice_draupnir_for_all_requires_restart | bool"
--- a/roles/custom/matrix-appservice-draupnir-for-all/tasks/setup_uninstall.yml
+++ b/roles/custom/matrix-appservice-draupnir-for-all/tasks/setup_uninstall.yml
@ -1,25 +0,0 @@
 ---
 - name: Check existence of matrix-appservice-draupnir-for-all service
  ansible.builtin.stat:
    path: "{{ devture_systemd_docker_base_systemd_path }}/matrix-appservice-draupnir-for-all.service"
  register: matrix_bot_draupnir_service_stat
 - when: matrix_bot_draupnir_service_stat.stat.exists | bool
  block:
    - name: Ensure matrix-appservice-draupnir-for-all is stopped
      ansible.builtin.service:
        name: matrix-appservice-draupnir-for-all
        state: stopped
        enabled: false
        daemon_reload: true
    - name: Ensure matrix-appservice-draupnir-for-all.service doesn't exist
      ansible.builtin.file:
        path: "{{ devture_systemd_docker_base_systemd_path }}/matrix-appservice-draupnir-for-all.service"
        state: absent
    - name: Ensure matrix-appservice-draupnir-for-all paths don't exist
      ansible.builtin.file:
        path: "{{ matrix_bot_draupnir_base_path }}"
        state: absent
--- a/roles/custom/matrix-appservice-draupnir-for-all/tasks/validate_config.yml
+++ b/roles/custom/matrix-appservice-draupnir-for-all/tasks/validate_config.yml
@ -1,9 +0,0 @@
 ---
 - name: Fail if required matrix-bot-draupnir variables are undefined
  ansible.builtin.fail:
    msg: "The `{{ item }}` variable must be defined and have a non-null value."
  with_items:
    - "matrix_appservice_draupnir_for_all_master_control_room_alias"
    - "matrix_bot_draupnir_container_network"
  when: "vars[item] == '' or vars[item] is none"
--- a/roles/custom/matrix-appservice-draupnir-for-all/templates/production-appservice.yaml.j2
+++ b/roles/custom/matrix-appservice-draupnir-for-all/templates/production-appservice.yaml.j2
@ -1,18 +0,0 @@
 homeserver:
  # The Matrix server name, this will be the name of the server in your matrix id.
  domain: "{{ matrix_domain }}"
  # The url for the appservice to call the client server API from.
  url: "{{ matrix_homeserver_url }}"
 # Database configuration for storing which Mjolnirs have been provisioned.
 db:
  engine: "postgres"
  connectionString: "{{ matrix_appservice_draupnir_for_all_database_connection_string }}"
 # A room you have created that scopes who can access the appservice.
 # See docs/access_control.md
 adminRoom: "{{ matrix_appservice_draupnir_for_all_master_control_room_alias }}"
 # This is a web api that the widget connects to in order to interact with the appservice.
 webAPI:
  port: 9000
--- a/roles/custom/matrix-appservice-draupnir-for-all/templates/production-bots.yaml.j2
+++ b/roles/custom/matrix-appservice-draupnir-for-all/templates/production-bots.yaml.j2
@ -1,83 +0,0 @@
 # The log level of terminal (or container) output,
 # can be one of DEBUG, INFO, WARN and ERROR, in increasing order of importance and severity.
 #
 # This should be at INFO or DEBUG in order to get support for Draupnir problems.
 logLevel: "INFO"
 # Whether or not Draupnir should synchronize policy lists immediately after startup.
 # Equivalent to running '!draupnir sync'.
 syncOnStartup: true
 # Whether or not Draupnir should check moderation permissions in all protected rooms on startup.
 # Equivalent to running `!draupnir verify`.
 verifyPermissionsOnStartup: true
 # Whether Draupnir should check member lists quicker (by using a different endpoint),
 # keep in mind that enabling this will miss invited (but not joined) users.
 #
 # Turn on if your bot is in (very) large rooms, or in large amounts of rooms.
 fasterMembershipChecks: false
 # A case-insensitive list of ban reasons to have the bot also automatically redact the user's messages for.
 #
 # If the bot sees you ban a user with a reason that is an (exact case-insensitive) match to this list,
 # it will also remove the user's messages automatically.
 #
 # Typically this is useful to avoid having to give two commands to the bot.
 # Advanced: Use asterisks to have the reason match using "globs"
 # (f.e. "spam*testing" would match "spam for testing" as well as "spamtesting").
 #
 # See here for more info: https://www.digitalocean.com/community/tools/glob
 # Note: Keep in mind that glob is NOT regex!
 automaticallyRedactForReasons:
  - "spam"
  - "advertising"
 # Whether or not to add all joined rooms to the "protected rooms" list
 # (excluding the management room and watched policy list rooms, see below).
 #
 # Note that this effectively makes the protectedRooms and associated commands useless
 # for regular rooms.
 #
 # Note: the management room is *excluded* from this condition.
 # Explicitly add it as a protected room to protect it.
 #
 # Note: Ban list rooms the bot is watching but didn't create will not be protected.
 # Explicitly add these rooms as a protected room list if you want them protected.
 protectAllJoinedRooms: false
 # Increase this delay to have Draupnir wait longer between two consecutive backgrounded
 # operations. The total duration of operations will be longer, but the homeserver won't
 # be affected as much. Conversely, decrease this delay to have Draupnir chain operations
 # faster. The total duration of operations will generally be shorter, but the performance
 # of the homeserver may be more impacted.
 backgroundDelayMS: 500
 # Misc options for command handling and commands
 commands:
  # Whether or not the `!draupnir` prefix is necessary to submit commands.
  #
  # If `true`, will allow commands like `!ban`, `!help`, etc.
  #
  # Note: Draupnir can also be pinged by display name instead of having to use
  # the !draupnir prefix. For example, "my_moderator_bot: ban @spammer:example.org"
  # will address only my_moderator_bot.
  allowNoPrefix: false
  # Any additional bot prefixes that Draupnir will listen to. i.e. adding `mod` will allow `!mod help`.
  additionalPrefixes:
    - "draupnir-bot"
    - "draupnir_bot"
    - "draupnir"
  # Whether or not commands with a wildcard (*) will require an additional `--force` argument
  # in the command to be able to be submitted.
  confirmWildcardBan: true
  # The default reasons to be prompted with if the reason is missing from a ban command.
  ban:
    defaultReasons: 
      - "spam"
      - "brigading"
      - "harassment"
      - "disagreement"
--- a/roles/custom/matrix-appservice-draupnir-for-all/templates/systemd/matrix-appservice-draupnir-for-all.service.j2
+++ b/roles/custom/matrix-appservice-draupnir-for-all/templates/systemd/matrix-appservice-draupnir-for-all.service.j2
@ -1,48 +0,0 @@
 #jinja2: lstrip_blocks: "True"
 [Unit]
 Description=Matrix Draupnir for All appservice
 {% for service in matrix_appservice_draupnir_for_all_systemd_wanted_services_list %}
 Requires={{ service }}
 After={{ service }}
 {% endfor %}
 {% for service in matrix_appservice_draupnir_for_all_systemd_required_services_list %}
 Wants={{ service }}
 {% endfor %}
 DefaultDependencies=no
 [Service]
 Type=simple
 Environment="HOME={{ devture_systemd_docker_base_systemd_unit_home_path }}"
 ExecStartPre=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} stop --time={{ devture_systemd_docker_base_container_stop_grace_time_seconds }} matrix-appservice-draupnir-for-all 2>/dev/null || true'
 ExecStartPre=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} rm matrix-appservice-draupnir-for-all 2>/dev/null || true'
 ExecStartPre={{ devture_systemd_docker_base_host_command_docker }} create \
 			--rm \
 			--name=matrix-appservice-draupnir-for-all \
 			--log-driver=none \
 			--user={{ matrix_user_uid }}:{{ matrix_user_gid }} \
 			--cap-drop=ALL \
 			--read-only \
 			--network={{ matrix_appservice_draupnir_for_all_container_network }} \
 			--mount type=bind,src={{ matrix_appservice_draupnir_for_all_config_path }},dst=/data/config,ro \
 			--mount type=bind,src={{ matrix_appservice_draupnir_for_all_data_path }},dst=/data \
 			{% for arg in matrix_appservice_draupnir_for_all_container_extra_arguments %}
 			{{ arg }} \
 			{% endfor %}
 			{{ matrix_appservice_draupnir_for_all_docker_image }} \
 			appservice -c /data/config/production-appservice.yaml -f /data/config/draupnir-for-all-registration.yaml -p {{ matrix_appservice_draupnir_for_all_appservice_port }} --draupnir-config /data/config/production-bots.yaml
 {% for network in matrix_appservice_draupnir_for_all_container_additional_networks %}
 ExecStartPre={{ devture_systemd_docker_base_host_command_docker }} network connect {{ network }} matrix-appservice-draupnir-for-all
 {% endfor %}
 ExecStart={{ devture_systemd_docker_base_host_command_docker }} start --attach matrix-appservice-draupnir-for-all
 ExecStop=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} stop --time={{ devture_systemd_docker_base_container_stop_grace_time_seconds }} matrix-appservice-draupnir-for-all 2>/dev/null || true'
 ExecStop=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} rm matrix-appservice-draupnir-for-all 2>/dev/null || true'
 Restart=always
 RestartSec=30
 SyslogIdentifier=matrix-appservice-draupnir-for-all
 [Install]
 WantedBy=multi-user.target
--- a/roles/custom/matrix-base/defaults/main.yml
+++ b/roles/custom/matrix-base/defaults/main.yml
@ -16,9 +16,6 @@ matrix_admin: ''
 # Global var to enable/disable encryption across all bridges with encryption support
 matrix_bridges_encryption_enabled: false
 # Global var to make encryption default/optional across all bridges with encryption support
 matrix_bridges_encryption_default: "{{ matrix_bridges_encryption_enabled }}"
 # Global var to enable/disable relay mode across all bridges with relay mode support
 matrix_bridges_relay_enabled: false
@ -154,7 +151,7 @@ matrix_host_command_chown: "/usr/bin/env chown"
 matrix_host_command_fusermount: "/usr/bin/env fusermount"
 matrix_host_command_openssl: "/usr/bin/env openssl"
-matrix_homeserver_url: "{{ ('https' if matrix_playbook_ssl_enabled else 'http') }}://{{ matrix_server_fqn_matrix }}"
+matrix_homeserver_url: "https://{{ matrix_server_fqn_matrix }}"
 # Specifies on which container network the homeserver is.
 matrix_homeserver_container_network: "matrix-homeserver"
@ -263,16 +260,7 @@ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_enabled: true
 matrix_playbook_public_matrix_federation_api_traefik_entrypoint_name: "{{ matrix_federation_traefik_entrypoint_name }}"
 matrix_playbook_public_matrix_federation_api_traefik_entrypoint_port: "{{ matrix_federation_public_port }}"
 matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port: "{{ matrix_federation_public_port }}"
-matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port_udp: "{{ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_http3_advertisedPort if matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_http3_enabled else '' }}"
+matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config: "{{ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_auto | combine(matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_custom, recursive=True) }}"
 matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config: "{{ (matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_default | combine (matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_auto)) | combine(matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_custom, recursive=True) }}"
 matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_http3_enabled: true
 matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_http3_advertisedPort: "{{ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_port }}"  # noqa var-naming
 matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_default: |
  {{
    ({'http3': {'advertisedPort': matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_http3_advertisedPort | int}})
    if matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_http3_enabled
    else {}
  }}
 matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_auto: {}
 matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config_custom: {}
@ -280,7 +268,6 @@ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_definition:
  name: "{{ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_name }}"
  port: "{{ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_port }}"
  host_bind_port: "{{ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port }}"
  host_bind_port_udp: "{{ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_host_bind_port_udp }}"
  config: "{{ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_config }}"
 # Controls whether to enable an additional Traefik entrypoint for the purpose of serving the homeserver's Client-Server API internally.
@ -304,7 +291,7 @@ matrix_playbook_public_matrix_federation_api_traefik_entrypoint_definition:
 # because addon services (e.g. bridges, bots) cannot properly pass a `Host` HTTP header when making
 # requests to the endpoint's address (e.g. `http://devture-traefik:8008/`).
 # This entrypoint only aims to handle a single "virtual host" - one dealing with the homeserver's Client-Server API.
-matrix_playbook_internal_matrix_client_api_traefik_entrypoint_enabled: "{{ matrix_playbook_reverse_proxy_type in ['playbook-managed-traefik', 'other-traefik-container'] }}"
+matrix_playbook_internal_matrix_client_api_traefik_entrypoint_enabled: true
 matrix_playbook_internal_matrix_client_api_traefik_entrypoint_name: matrix-internal-matrix-client-api
 matrix_playbook_internal_matrix_client_api_traefik_entrypoint_port: 8008
 matrix_playbook_internal_matrix_client_api_traefik_entrypoint_host_bind_port: ''
--- a/roles/custom/matrix-base/tasks/validate_config.yml
+++ b/roles/custom/matrix-base/tasks/validate_config.yml
@ -85,15 +85,3 @@
      To clean up your server from mx-puppet-skype's presence, see this changelog entry: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/CHANGELOG.md#mx-puppet-skype-removal.
      If you still need bridging to Skype, consider switching to the go-skype bridge instead. See `docs/configuring-playbook-bridge-go-skype-bridge.md`.
  when: "'matrix_mx_puppet_skype_enabled' in vars"
 - name: Fail if mautrix-instagram and mautrix-meta-instagram are in conflict
  ansible.builtin.fail:
    msg: >-
      Your configuration enables both the old mautrix-instagram bridge and the new mautrix-meta-instagram bridge.
      By default, both bridges are configured to use the same bridge bot username (`@{{ matrix_mautrix_meta_instagram_appservice_username }}:{{ matrix_domain }}`) which is a conflict.
      We recommend that you disable at least one of the bridges (preferrably the old mautrix-instagram bridge), or to resolve the conflict in another way.
      To resolve the conflict without disabling a bridge, consider adjusting one of `matrix_mautrix_instagram_appservice_bot_username` or `matrix_mautrix_meta_instagram_appservice_username` - they both have a value of {{ matrix_mautrix_meta_instagram_appservice_username }} right now.
  when:
    - matrix_mautrix_instagram_enabled | bool
    - matrix_mautrix_meta_instagram_enabled | bool
    - matrix_mautrix_instagram_appservice_bot_username == matrix_mautrix_meta_instagram_appservice_username
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Slavi Pantaleev	116e9fad86	Minor cleanups	2024-01-17 10:53:20 +02:00
Slavi Pantaleev	396ab9f200	Fix incorrect indication in homeserver.yaml.j2	2024-01-17 10:53:12 +02:00
Slavi Pantaleev	055cbf3208	Add to_json to various Synapse tuning related configs	2024-01-17 10:34:20 +02:00
Catalan Lover	2481c9cebc	Fix YML Error The playbook is not happy with the previous state of this patch so this commit hopefully fixes it	2024-01-17 10:32:25 +02:00
Catalan Lover	e5add0fd48	Updated Auto Tune figures Autotuned figures have been bumped in consultation with other community members as to a reasonable level. Please note these defaults are more on the one of each workers side than they are on the monolith Side.	2024-01-17 10:32:25 +02:00
Catalan Lover	ecb3bdccde	Add vars to Synapse main.yml to control cache related config This commit adds various cache related vars to main.yml for Synapse. Some are auto tune and some are just adding explicit ways to control upstream vars.	2024-01-17 10:32:24 +02:00
Catalan Lover	ec838dc4c3	Modify Synapse Cache Factor to use Auto Tune Synapse has the ability to as it calls in its config auto tune caches. This ability lets us set very high cache factors and then instead limit our resource use. Defaults for this commit are 1/10th of what Element apparently runs for EMS stuff and matrix.org on Cache Factor and upstream documentation defaults for auto tune.	2024-01-17 10:31:12 +02:00