Auto-generate the provisioning shared secret (to enable the provisioning
API), route the whole bridge HTTP port via Traefik under
`<matrix-fqn>/bridges/meta-instagram`, and populate
appservice.public_address, reusing the matrix_bridges_exposure_*
mechanism. The labels template gate is widened so the exposure router is
emitted even when metrics are disabled (the exposure router reuses the
existing appservice Traefik service on port 29319).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Auto-generate the provisioning shared secret (to enable the provisioning
API), route the whole mautrix-whatsapp HTTP port via Traefik under
`<matrix-fqn>/bridges/whatsapp`, and populate appservice.public_address,
reusing the matrix_bridges_exposure_* mechanism.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route the whole mautrix-bluesky HTTP port via Traefik under
`<matrix-fqn>/bridges/bluesky` and populate the existing
appservice.public_address, reusing the matrix_bridges_exposure_*
mechanism. The provisioning shared secret is already auto-generated in
group_vars, so the provisioning API is enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route the whole mautrix-twitter HTTP port via Traefik under
`<matrix-fqn>/bridges/twitter` and populate the existing
appservice.public_address, reusing the matrix_bridges_exposure_*
mechanism. The provisioning shared secret is already auto-generated in
group_vars, so the provisioning API is enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route the whole mautrix-signal HTTP port via Traefik under
`<matrix-fqn>/bridges/signal` and populate appservice.public_address,
reusing the matrix_bridges_exposure_* mechanism. The provisioning shared
secret is already auto-generated in group_vars, so the provisioning API
is enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route the whole mautrix-telegram HTTP port via Traefik under
`<matrix-fqn>/bridges/telegram` and populate appservice.public_address,
reusing the matrix_bridges_exposure_* mechanism. The provisioning shared
secret is already auto-generated in group_vars, so the provisioning API
is enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a generic mechanism for exposing bridges' HTTP API (the provisioning
API, etc.) publicly on the Matrix domain, so tools like mautrix-manager
(https://github.com/mautrix/manager) can drive bridge login.
- Introduce global matrix_bridges_exposure_* vars (on by default),
exposing each supported bridge under `<matrix-fqn>/bridges/<bridge>`.
- mautrix-gmessages: make the provisioning shared secret configurable
(auto-generated in group_vars) so the provisioning API is enabled,
route the whole bridge HTTP port via Traefik, and populate
appservice.public_address.
Requests are authenticated by the bridge itself (per-user Matrix access
token for the provisioning API, homeserver token for the appservice
endpoints), not by the reverse proxy.
This is the first bridge converted; the other mautrix bridges will follow.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
As of tuwunel v1.8.0, the ip_range_denylist applies to push gateway
delivery as well, so surface it as an Ansible variable using the
default/auto/custom merge pattern. The default mirrors tuwunel's own
upstream denylist (RFC1918, loopback, multicast, and other unroutable
ranges), matching the identical list already used for Synapse's
matrix_synapse_url_preview_ip_range_blacklist.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The role shipped its own copy of the bridge's Dockerfile and templated it
over the cloned source before building. That copy had already drifted from
upstream (e.g. missing libheif-plugin-libde265) and required separate
maintenance (Renovate bumping the base image here instead of upstream).
Build from the cloned repo's own Dockerfile instead, matching every other
self-build role (e.g. matrix-bridge-steam). The Dockerfile now tracks the
pinned bridge version automatically.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add the matrix-rustpush-bridge role, a Matrix <-> iMessage bridge built
on the mautrix-go bridgev2 framework using RustPush (OpenBubbles backend).
Unlike the existing mautrix-imessage/wsproxy bridge, it talks directly to
Apple's push notification service, so it needs neither a running Mac nor a
wsproxy on the homeserver. Each user supplies a hardware key extracted from a
Mac through the bridge bot's login flow.
The bridge uses its own bot username and puppet namespace (rustpushbot,
rustpush_*) so it does not collide with the wsproxy iMessage bridge.
This bridge is in early development and may have stability issues.
NPM "Proxy Hosts" page is only for http/https 80/443 - it is not possible to add a name such as "matrix.example.com:port".
Instead, the Streams page might work for what is intended here (federation traffic) - to proxy stream anything on 8448 to 8449.
Continuwuity has no native enable-captcha toggle; it enables the ReCAPTCHA
registration flow based on the presence of a private site key. The playbook
previously always rendered empty `recaptcha_site_key`/`recaptcha_private_site_key`
values, which made Continuwuity enable a broken captcha flow and break
registration in some clients.
The keys are now only rendered when both are configured, gated by a derived
`matrix_continuwuity_recaptcha_enabled` flag in the role's `vars/main.yml`. A
consistency check fails the play when exactly one of the two keys is set.
Fixes#5329
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Slavi Pantaleev
Aine
renovate[bot]
Jason LaGuidice
Hollie Hutchinson
dependabot[bot]
LunarFox
Catalan Lover