Add per-room ignores for bot and webhook senders #88

New issue

Open

opened 2026-05-02 04:41:58 +00:00 by hongminhee · 0 comments

hongminhee commented

2026-05-02 04:41:58 +00:00

I think a per-channel ignored-sender list would cover the case. PluralKit already gets a hardcoded carve-out in src/d2m/actions/speedbump.js, and the bridge skips its own webhook and ephemeral messages in src/d2m/event-dispatcher.js, but nothing user-configurable exists.

What it should do

On the Discord side, I'd want to drop a message before it's bridged based on:

the bot/application ID (message.application_id, or the application behind a webhook)
the webhook ID (message.webhook_id)
the author ID for bot users

On the d2m side, my guess is that this check would live near the existing webhook filter in MESSAGE_CREATE (and the matching MESSAGE_UPDATE / MESSAGE_DELETE handlers).

For m2d, the same idea would be filtering by sender MXID. That would help when a GitHub forge bridge or hookshot bot is posting into the same Matrix room. That looks related to the eventSenderIsFromDiscord check in src/m2d/event-dispatcher.js.

Scope

Per-channel/per-room is probably the right granularity, since the same bot might be welcome in some rooms and unwelcome in others. The schema already has channel_room carrying per-channel state; a separate ignored_sender table keyed by (channel_id, sender_id) would avoid changing existing channel_room rows. Guild-wide and global ignores are nice to have but not essential.

Configuration UI

I only really need one way to configure it. Any of these would work:

A slash command on Discord (/bridge ignore @bot, /bridge unignore @bot, /bridge ignored), matching the existing handlers in src/discord/.
A bot command in the bridged Matrix room.
A page in the web dashboard under src/web/, alongside the existing H3 routes and Pug templates.
Manual SQL only, if you'd rather keep this surface small.

Open questions

Should ignored messages be fully silent, or leave a debug log? I'd lean fully silent.
If a message was bridged before the sender was ignored, should later edits/deletes still propagate? I think yes for deletes (so the Matrix copy doesn't get stranded), no for edits.
Any interaction with speedbump? I don't think so, since speedbump only triggers on the hardcoded PluralKit application ID.

I can work on a PR once you're happy with the shape.

Some bridged Discord channels get noisy because most of the traffic is bot output: GitHub/Forgejo hooks, CI posts, log relays, dashboard pings. Once those channels are bridged, every event gets duplicated on Matrix. For users who already follow GitHub on Matrix directly (or just don't want the noise), there's no way to opt out without unbridging the channel. I think a per-channel ignored-sender list would cover the case. PluralKit already gets a hardcoded carve-out in *src/d2m/actions/speedbump.js*, and the bridge skips its own webhook and ephemeral messages in *src/d2m/event-dispatcher.js*, but nothing user-configurable exists. ### What it should do On the Discord side, I'd want to drop a message before it's bridged based on: - the bot/application ID (`message.application_id`, or the application behind a webhook) - the webhook ID (`message.webhook_id`) - the author ID for bot users On the d2m side, my guess is that this check would live near the existing webhook filter in `MESSAGE_CREATE` (and the matching `MESSAGE_UPDATE` / `MESSAGE_DELETE` handlers). For m2d, the same idea would be filtering by sender MXID. That would help when a GitHub forge bridge or hookshot bot is posting into the same Matrix room. That looks related to the `eventSenderIsFromDiscord` check in *src/m2d/event-dispatcher.js*. ### Scope Per-channel/per-room is probably the right granularity, since the same bot might be welcome in some rooms and unwelcome in others. The schema already has `channel_room` carrying per-channel state; a separate `ignored_sender` table keyed by `(channel_id, sender_id)` would avoid changing existing `channel_room` rows. Guild-wide and global ignores are nice to have but not essential. ### Configuration UI I only really need one way to configure it. Any of these would work: 1. A slash command on Discord (`/bridge ignore @bot`, `/bridge unignore @bot`, `/bridge ignored`), matching the existing handlers in *src/discord/*. 2. A bot command in the bridged Matrix room. 3. A page in the web dashboard under *src/web/*, alongside the existing H3 routes and Pug templates. 4. Manual SQL only, if you'd rather keep this surface small. ### Open questions - Should ignored messages be fully silent, or leave a debug log? I'd lean fully silent. - If a message was bridged before the sender was ignored, should later edits/deletes still propagate? I think yes for deletes (so the Matrix copy doesn't get stranded), no for edits. - Any interaction with speedbump? I don't think so, since speedbump only triggers on the hardcoded PluralKit application ID. I can work on a PR once you're happy with the shape.