The metrics endpoint was the only thing this bridge ever routed through
Traefik. With it gone, the container was still labeled `traefik.enable=true`
without defining any router, which makes Traefik fall back to its default
rule and produce a router pointing at nothing. It was also joining the
reverse-proxy network for no reason.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487
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>
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.
Slavi Pantaleev
jasonlaguidice