Matterbridge: Discord can use just one webhook

[qaisjp]

Is your feature request related to a problem? Please describe.
There is a limit to the number of webhooks you can create on Discord. And creating webhooks is painful manual work.

Describe the solution you'd like

1. The bridge should not need a webhook per channel, it should just edit webhooks
2. The bridge should create/delete webhooks automatically when it starts/stops

Describe alternatives you've considered
Only enabling the edit feature (you still have to manually create _one_ webhook), and this still means that only one webhook is needed per guild, which is awesome.

Additional context
I currently do this in my bot. When the bot starts, it deletes all webhooks that were previously created by the bot (in case the bot crashed). It uses a "prefix" to determine which webhook(s) are ours. This is not necessary if auto creation/deletion is not implemented (as per "alternatives" above).

discordgo supports editing of webhooks as of 0.19.0 (this is the version that matterbridge currently uses)

The reason auto-creation/deletion is to maintain "conversations" across channels. At the time of implementation (at least 1 year ago), editing a webhook prevented "stacking" of messages by the same user; i.e, in the following scenario, Bob's avatar would appear twice, instead of once.

1. Bob speaks in #general (webhook edited to be Bob, if not already Bob)
2. Alex speaks in #random (webhook edited to be Alex)
3. Bob speaks in #general (webhook edited to be Bob, and Bob's avatar appears twice, instead of once)

This will be re-tested. If this bug no longer occurs, sticking to one webhook will work. Otherwise, multiple webhooks are required to enable stacking of avatars.

Example implementation

See example source: https://github.com/qaisjp/go-discord-irc/tree/master/transmitter.

This code has a bug where if something happens Discord-side, webhook state will become out of sync, and the bridge will send messages to the wrong channel. This is because the bridge thinks the webhook is on another channel; a simple fix for this is to check the channel every message send, but this introduces some latency.

Any PR submitted that fixes this issue should not introduce this bug.

I'm happy to work on this!

[42wim]

Good idea, go for it! :)
Do users have to add extra permissions for this on discord or is this by default possible?
On the matterbridge side maybe add a AutoWebhook option (not sure yet if this should be enabled by default)

[qaisjp]

Do users have to add extra permissions for this on discord or is this by default possible?

This needs the "Manage Webhooks" permission.

[nylen]

On the matterbridge side maybe add a AutoWebhook option (not sure yet if this should be enabled by default)

I'm not sure the AutoWebhook option is needed. This could also work as follows:

• If a WebhookURL is specified for the account connection (in the [discord.servername] section along with the API token), then it is treated as a global webhook and the channel is modified each time it is used. (Currently, a webhook URL specified in this section will always send to the single channel it is configured for, regardless of gateway settings. This doesn't seem like desirable behavior.)

• If a WebhookURL is specified in the gateway settings, then it is treated as a single-channel webhook and the channel is not edited. This is the same behavior as today.

I have working code for this, let me know if the approach is acceptable and I will submit a PR.

At the time of implementation (at least 1 year ago), editing a webhook prevented "stacking" of messages by the same user; i.e, in the following scenario, Bob's avatar would appear twice, instead of once.

I am not sure if this is an issue or not - so far, I have only tested relaying messages from a single account. However, I think a multi-webhook approach would still be far more complicated.

[qaisjp]

Currently, a webhook URL specified in this section will always send to the single channel it is configured for, regardless of gateway settings. This doesn't seem like desirable behavior.

Indeed, I found this a little bit odd — it's good to know it works as expected øn a gateway level.

I have working code for this, let me know if the approach is acceptable and I will submit a PR.

Your approach seems good!

I am not sure if this is an issue or not - so far, I have only tested relaying messages from a single account. However, I think a multi-webhook approach would still be far more complicated.

I'll give your (eventual) PR a test and see if multiple are still necessary.

It is indeed a little complicated, so if what I reproduced in 2017 still occurs, it would be worth evaluating the trade-off between making messages appear more natural vs the additional complexity.

I'm not sure the AutoWebhook option is needed.

What if WebhookURL="auto" would enable auto-creation of webhook(s), so if the bot has the "Manage Webhook" permission, it can make use of those permissions to make things a little more convenient?

[nylen]

What if WebhookURL="auto" would enable auto-creation of webhook(s)

My preference would be to save this for a future enhancement beyond the initial PR. It's going to need logic to find and re-use the webhook(s) across runs of the app, which is tricky because right now there's no persistent data storage.

Another thing to think about there is that Discord has a pretty low number of webhook slots (10). Having a bot automatically create them, especially multiple, seems a bit invasive.

if what I reproduced in 2017 still occurs, it would be worth evaluating the trade-off between making messages appear more natural vs the additional complexity.

I'll test this out in more detail, but I think it's also not going to be a big problem. If this still occurs, then you can work around it by creating a channel-specific webhook for one or more channels that are frequently used. This webhook will always be used for that channel, ensuring that its messages always come through correctly, and the global webhook will be used for all other channels.

[nylen]

PR is up at #681.

[qaisjp]

My preference would be to save this for a future enhancement beyond the initial PR.

Totally, that's what I was thinking anyway 🙂

[Helcaraxan]

From what I can see this issue / FR has been resolved so closing it. Feel free to re-open if that is not the case.

[nylen]

https://github.com/42wim/matterbridge/pull/681#issuecomment-452097597

I don't think this PR fixes #674 entirely as I would still like to implement auto-creation, for convenience sake.

Might be a good idea to open a new issue to follow up on this (try to automatically create the Discord webhook instead of requiring that this be done manually).