Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Documentation update

* New files for role

* Update existing files to add support for matrix-steam-bridge

* Typos and misc fixes

* Change docker tag to latest until version # is stable

* Align bridge permissions

* Correct user localpart

* Remove trailing +

* Fix syslog identifier

* Actually enable the service correctly

* One more typo fix

* Third time's the charm

* Fix config file paths

* Fix config after bridge repo changes

* Add default appservice public address - set public_media to false by default for testing

* Fix default config for steamkit-service path

* Fix bluesky reference

* Fix default container path

* Fix appservice connection to http for internal, change port to standard 8080

* Fix appservice port

* Enable public_media by default, add labels

* Enable public_media by default, add labels

* Allow bridge to update its own config and generate public_media signing key

* Add deterministic public_media_signing_key, expose portal cleanup

* Change default public_media path to omit `matrix.` from the path as it has been found that URLs generated by the bridge will only match {{ matrix_domain }}

* Remove domain re-write

* Revert "Change default public_media path to omit `matrix.` from the path as it has been found that URLs generated by the bridge will only match {{ matrix_domain }}"

This reverts commit 5f399effb9.

* Fix TLS label if playbook TLS is disabled

* Match default bridge TLS config

* Related to 3daf14d69 and 60ab08014 which enable async media by default for mautrix-go bridges

* Adjust matrix-bridge-steam files to add new line at the end of files

* Pin matrix-bridge-steam (latest -> 1.0.3)

---------

Co-authored-by: Slavi Pantaleev <slavi@devture.com>

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/4549

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/4445

Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>

* Add matrix_bridges_msc4190_enabled flag for using msc4190 on supported mautrix bridges.

* Apply to_json to msc4190 in mautrix configs

* Add | to_json to mautrix bridge registration io.element.msc4190.

* require matrix_synapse_experimental_features_msc3202_device_masquerading_enabled for matrix_bridges_msc4190_enabled

* Also add msc4190 support for mautrix-telegram

Fixup for 784a5aaef4.

* one var to control encryption across all bridges

* move var to matrix-base

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2427

This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.

Not doing {% if matrix_admin %} checks in the YAML also fixes some issues
with indentation being incorrect sometimes.

This should be backward compatible, except for mautrix-signal's case
where `matrix_mautrix_signal_bridge_permissions` previously existed
as a string, not a dictionary. `tasks/validate_config.yml` will catch
the problem an even provide a quick fix.

"Community" support

- has been removed from mautrix/facebook in v0.3.3:
  31cac6fb5e

- has been removed from mautrix/signal in v0.2.2:
  1f27a608a6

- will be removed in the next mautrix/instagram release:
  e2ae1ca503

- will be removed in the next mautrix/twitter release:
  3893075265

Updates based off the variable names used in mautrix-facebook role.

Also update port number in defauts/main.yml, and disable presence
checking, because Twitter doesn't support that.

Source: 12f420ab95/mautrix_twitter/example-config.yaml

find roles/matrix-bridge-mautrix-twitter -type f -exec sed -i \
  -e 's/facebook/twitter/g' \
  -e 's/Facebook/Twitter/g' \
  -e 's/FB/Twitter/g' \
  -e 's/fb/twitter/g' {} +

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/806

I had intentionally held it back in 39ea3496a4
until:
- it received more testing (there were a few bugs during the
migration, but now it seems OK)
- this migration guide was written

If a service is enabled, a database for it is created in postgres with a uniqque password. The service can then use this database for data storage instead of relying on sqlite.

This also disables presence if it's disabled for Synapse.

Related to #193, but for the Facebook bridge.
(other bridges can be changed to do the same later).

This patch makes the bridge configuration entirely managed by the
Ansible playbook. The bridge's `config.yaml` and `registration.yaml`
configuration files are regenerated every time the playbook runs.

This allows us to apply updates to those files and to avoid
people having to manage the configuration files manually on the server.

-------------------------------------------------------------

A deficiency of the current approach to dumping YAML configuration in
`config.yaml` is that we strip all comments from it.
Later on, when the bridge actually starts, it will load and redump
(this time with comments), which will make the `config.yaml` file
change.

Subsequent playbook runs will report "changed" for the
"Ensure mautrix-facebook config.yaml installed" task, which is a little
strange.

We might wish to improve this in the future, if possible.

Still, it's better to have a (usually) somewhat meaningless "changed"
task than to what we had -- never rebuilding the configuration.