Skip to content

bridgev2: add bridge_remote_leave config option#502

Open
Deln0r wants to merge 1 commit into
mautrix:mainfrom
Deln0r:feat/issue-450-bridge-remote-leave
Open

bridgev2: add bridge_remote_leave config option#502
Deln0r wants to merge 1 commit into
mautrix:mainfrom
Deln0r:feat/issue-450-bridge-remote-leave

Conversation

@Deln0r
Copy link
Copy Markdown

@Deln0r Deln0r commented May 13, 2026

Closes #450.

Summary

Adds a new bridge_remote_leave config option that is the symmetric counterpart of the existing bridge_matrix_leave. When the bridge receives a membership-change event from the remote network with Membership == leave and the operator has set bridge_remote_leave: false, syncUser drops the event instead of applying it to the corresponding Matrix room. The user keeps access to the Matrix room and its existing history; new bridged messages between them and the remote group naturally stop because the remote relationship is gone.

Use case from the linked issue: a user leaves a WhatsApp / Signal / Telegram group but wants to keep the history accessible on Matrix, rather than being kicked out of the portal alongside the remote.

Default

The example config and the upgrade list set the new key to true, which preserves the current behavior for existing deployments on a silent config upgrade. Operators that want the new behavior opt in by flipping it to false.

Files touched

File Change
bridgev2/bridgeconfig/config.go Add BridgeRemoteLeave bool field next to BridgeMatrixLeave
bridgev2/bridgeconfig/upgrade.go helper.Copy entry so the key round-trips through config upgrades
bridgev2/matrix/mxmain/example-config.yaml New bridge_remote_leave: true line with explanatory comment
bridgev2/portal.go Drop branch at the top of syncUser

Scope (intentionally narrow)

The follow-up the issue author suggested — "set the user's power level to 0 and raise the send-message level so the bot can moderate further behavior" — is left for a separate change. That touches the power-level state machine and warrants its own discussion. With this PR in place, the bot can keep the user in the room as a member, and operators can layer the power-level handling on top later.

Test plan

The diff carries no new test cases (the change is gated by a config-default that preserves existing behavior, and there is no existing membership-sync test scaffold in the repo to extend cheaply). Verified locally:

$ go build -tags=goolm ./bridgev2/...
$ go vet -tags=goolm ./bridgev2/...

Happy to add a unit / integration test if you want one — let me know your preferred shape.

…r they leave on the remote side

Symmetric counterpart of the existing bridge_matrix_leave option. When
the bridge sees a membership change from the remote network with
Membership == leave and the operator has set bridge_remote_leave: false,
syncUser drops the leave instead of applying it to the corresponding
Matrix room. The user keeps access to the room and its existing
history; new traffic between them and the remote group no longer
bridges because the remote relationship is gone.

The example config and the upgrade list grow a new entry, defaulting
to true so existing deployments keep the current behavior on a
silent upgrade.

The "set the power level to 0 and raise the send-message level"
follow-up suggested in mautrix#450 is intentionally out of scope here; it
needs a broader power-level handling discussion. With this change in
place, an operator can keep the user in the room and the bot can
still moderate further behavior on top.

Closes mautrix#450.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Don't leave matrix room when leaving group in remote chat

1 participant