Hi, I have a small bridgev2 behavior proposal. Apologies for not asking in #go:maunium.net first; my Matrix server is unfederated.
Currently Bridge.QueueRemoteEvent calls MarkInPortal for every remote event after resolving the portal. That means a Matrix user who intentionally left a portal room can be re-invited/rejoined by metadata-only remote activity such as receipts, typing, chat metadata syncs, reaction syncs, or backfill-related events, depending on the bridge.
Would you be open to a shared bridge config option that controls which remote event types are allowed to repair that local leave?
One possible shape:
bridge:
rejoin_on_events:
- message
- message_upsert
- edit
- reaction
- reaction_remove
- reaction_sync
- message_remove
- backfillThe default could preserve current-ish upstream behavior for visible content events, while operators that want quieter semantics could narrow it to something like:
bridge:
rejoin_on_events:
- message
- message_upsertThe stable event names could map to the existing bridgev2 RemoteEventType values, e.g. message, message_upsert, edit, reaction, reaction_remove, reaction_sync, message_remove, read_receipt, delivery_receipt, mark_unread, typing, chat_info_change, chat_resync, and backfill.
I have a local patch that adds this as shared bridge config, validates unknown names at config load, gates the QueueRemoteEvent -> MarkInPortal path, and also suppresses participant-sync membership repair when handling a disallowed remote event context. go test ./bridgev2 passes locally.
Before opening a PR, I wanted to check whether this is a policy knob you would accept in bridgev2, and whether you prefer a different name, default set, or enforcement location.
Hi, I have a small bridgev2 behavior proposal. Apologies for not asking in
#go:maunium.netfirst; my Matrix server is unfederated.Currently
Bridge.QueueRemoteEventcallsMarkInPortalfor every remote event after resolving the portal. That means a Matrix user who intentionally left a portal room can be re-invited/rejoined by metadata-only remote activity such as receipts, typing, chat metadata syncs, reaction syncs, or backfill-related events, depending on the bridge.Would you be open to a shared bridge config option that controls which remote event types are allowed to repair that local leave?
One possible shape:
The default could preserve current-ish upstream behavior for visible content events, while operators that want quieter semantics could narrow it to something like:
The stable event names could map to the existing bridgev2
RemoteEventTypevalues, e.g.message,message_upsert,edit,reaction,reaction_remove,reaction_sync,message_remove,read_receipt,delivery_receipt,mark_unread,typing,chat_info_change,chat_resync, andbackfill.I have a local patch that adds this as shared bridge config, validates unknown names at config load, gates the
QueueRemoteEvent -> MarkInPortalpath, and also suppresses participant-sync membership repair when handling a disallowed remote event context.go test ./bridgev2passes locally.Before opening a PR, I wanted to check whether this is a policy knob you would accept in bridgev2, and whether you prefer a different name, default set, or enforcement location.