Add MatrixMeshtasticRelay

[luschmar]

I want to add Meshtastic to the deployment. For that I created a galaxy Role https://github.com/luschmar/ansible-role-mmrelay

[spantaleev]

It'd be better if this role is made part of the playbook (roles/custom/matrix-meshstatic-relay/), so that playbook users would not need to trust a 3rd party repository for role installation.

Would you be open to reworking this PR, so that it includes the full role here?

[luschmar]

@spantaleev Of course. Since more playbooks have been moved to other repositories, I thought this would be the right approach.

[spantaleev]

Thanks for the initial PR, @luschmar! 🙏

Reworked this into a fully vendored role at roles/custom/matrix-bridge-meshtastic-relay/ so playbook users don't have to trust a 3rd-party galaxy source. The role is adapted to match the conventions used by sibling bridges like matrix-bridge-heisenbridge and matrix-bridge-mautrix-bluesky.

Key user-facing changes vs. your original galaxy role (worth noting if you're tracking it elsewhere):

• Variables renamed: matrix_meshtastic_relay_auth_password → matrix_meshtastic_relay_matrix_bot_password, matrix_meshtastic_relay_auth_bot_user_id → matrix_meshtastic_relay_matrix_bot_user_id.
• Removed matrix_meshtastic_relay_identifier; the service/container name is hardcoded to matrix-meshtastic-relay (matches the pattern other bridges follow).
• base_path default is now {{ matrix_base_data_path }}/meshtastic-relay; file ownership uses matrix_user_name/matrix_user_group.
• Homeserver URL defaults to the playbook's internal matrix_addons_homeserver_client_api_url rather than the public https://{{ matrix_host }}, so the relay reaches the homeserver over the internal container network.
• Config rendering: instead of a Jinja config.yaml template, the config is now built from a matrix_meshtastic_relay_configuration_default dict that users can extend/override via matrix_meshtastic_relay_configuration_extension_yaml.

Container hardening also got a small bump: --cap-drop=ALL, --read-only with tmpfs for /tmp and /.cache, and the broken # --cap-drop=ALL \ inline comment in the systemd unit was removed (it was being passed through as an argument to docker create).

Docs live at docs/configuring-playbook-bridge-meshtastic-relay.md and there's a CHANGELOG entry under 2026-04-24.

⚠️ Heads-up: this was not end-to-end tested. No actual Meshtastic device was harmed (or bridged) in the making of this rework. The changes above are a fair amount of surface area, so regressions are very possible. If you (or anyone trying this) spot something broken or awkward, please open a follow-up PR, much appreciated!

[spantaleev]

Heads-up @luschmar: upstream shipped v1.3.x in the meantime, and the Renovate bump PR made me realize the role needs more than a version tag change.

v1.3.0 introduced a unified MMRELAY_HOME=/data runtime model (credentials, database, logs, E2EE store, plugins all live under /data). The legacy /app/* layout still works until v1.4, but it seemed cleaner to adopt the new model now while nobody's running this yet.

Pushed to master as 8e2545a. In summary, I bumped the version to 1.3.5 and rearranged the container mounts:

• matrix_meshtastic_relay_config_path is mounted read-only at /config (Ansible-managed)
• matrix_meshtastic_relay_data_path is mounted read-write at /data (runtime state)
• Dropped the matrix_meshtastic_relay_logs_path variable (mmrelay auto-creates logs/ under /data)
• Container command is overridden to mmrelay --config /config/config.yaml so the Ansible-managed config file stays outside the runtime data directory, consistent with how other bridges in this playbook split config vs data
• Removed the hardcoded /app/data/... database and e2ee store_path overrides from the default config; MMRELAY_HOME defaults now place them under _data_path/database/ and _data_path/matrix/store/

Still completely untested on my end, same caveat as before: if anything looks wrong, a follow-up PR is very welcome.

[luschmar]

Thank you very much! I will migrate this as soon as possible and share my feedback. Please be patient, as I might need a bit more time.