bridgev2: add bridge_remote_leave config option#502
Open
Deln0r wants to merge 1 commit into
Open
Conversation
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #450.
Summary
Adds a new
bridge_remote_leaveconfig option that is the symmetric counterpart of the existingbridge_matrix_leave. When the bridge receives a membership-change event from the remote network withMembership == leaveand the operator has setbridge_remote_leave: false,syncUserdrops 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 tofalse.Files touched
bridgev2/bridgeconfig/config.goBridgeRemoteLeave boolfield next toBridgeMatrixLeavebridgev2/bridgeconfig/upgrade.gohelper.Copyentry so the key round-trips through config upgradesbridgev2/matrix/mxmain/example-config.yamlbridge_remote_leave: trueline with explanatory commentbridgev2/portal.gosyncUserScope (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:
Happy to add a unit / integration test if you want one — let me know your preferred shape.