* Add DisablePingEveryoneHere/DisablePingRoles/DisablePingUsers keys to config
* Add basic AllowedMentions behavior to discord webhooks
* Initialize b.AllowedMentions on Discord Bridger init
* Call b.getAllowedMentions on each webhook to allow config hot reloading
* Add AllowedMentions on all Discord webhooks/messages
* Add DisablePingEveryoneHere/DisablePingRoles/DisablePingUsers to matterbridge.toml.sample
* Change 'Disable' for 'Allow' and revert logic in Discord AllowedMentions
* Update Discord AllowedMentions in matterbridge.toml.sample
* Fix typo in DisableWebPagePreview
* Replace 'AllowPingEveryoneHere' with 'AllowPingEveryone'
* Replace 3 AllowPingEveryone/Roles/Users bools with an array
* Fix typo
Without this declared, it seems that Discord will not send any member update
events after connection, even if the privileged gateway intent is enabled for
the bot in settings. This causes nick tracking to get out of sync when people
change their nicks after the bot connects.
See: https://discord.com/developers/docs/topics/gateway#gateway-intents
* Use valid transmitter Log default (discord)
Using a logger created by `log.NewEntry(nil)` would crash. (matterbridge does not encounter this issue as it updates the Log field manually.)
* Add mod_slack_webhook support to the XMPP bridge
* Replace b.webhookURL with b.GetString
* Do not return a message ID on webhook POST
* Add the XMPP webhook to the sample configuration
Discord message references have been designed in a way for this to
support cross-channel or even cross-guild references in the future.
This will ensure the ParentID is *not* set when the message refers to a
message that was sent in a different channel.
Webhooks don't support the threading yet, so this is token only.
In discord you can reply on each message of a thread, but this is not possible in mattermost (so some changes added there to make sure we always answer on the rootID of the thread).
Also needs some more testing with slack.
update : It now also uses the token when replying to a thread (even if webhooks are enabled), until webhooks have support for threads.
* irc: add support for stateless bridging via draft/relaymsg
As discussed at https://github.com/42wim/matterbridge/issues/667#issuecomment-634214165
* irc: handle the draft/relaymsg tag in spoofed messages too
* Apply suggestions from code review
Co-authored-by: Wim <wim@42.be>
* Run gofmt on irc.go
* Document relaymsg in matterbridge.toml.sample
Co-authored-by: Wim <wim@42.be>
This makes the handlers run in a seperate go-routine in girc, and makes
sure that girc isn't blocked on executing PONG requests when
matterbridge takes a long time handling the incoming message.
This can happen when another bridge is in a backoff state where the
backoff time exceeds the IRC ping timeout.
* matrix: send the display name (the nickname in matrix parlance) instead of the user name
There is also the option UseUserName (already in use by the discord bridge) to turn back to the old behavior.
* matrix: update displayNames on join events
* matrix: introduce a helper.go file to keep matrix.go size reasonable
When using the webhook, the previous method to edit a message was to
delete the old one via the classical API, and to create a new message
via the webhook. While this works, this means that editing "old" messages
lead to a mess where the chronological order is no longer respected.
This uses an hidden API explained in https://support.discord.com/hc/en-us/community/posts/360034557771
to achieve a proper edition using the webhook API.
The obvious downside of this approach is that since it is an
undocumented API for now, so there is no stability guarantee :/
This includes at least c-source-files, cpp-source-files,
markdown-files, Rust-files, and plaintext files.
We already allow uploading arbitrary executables. (And javascript-files,
coincidentally.) Not permitting these other text files would be highly unexpected.
The current way to get the correct JID of a WhatsApp group is to dump all JIDs to the log and grab the right one. This is working for for groups fine but not for broadcast, as they are not print out.
According to https://www.npmjs.com/package/@noamalffasy/js-whatsapp we have these possibilities:
* Chats: `[country code][phone number]@s.whatsapp.net`
* Groups: `[country code][phone number of creator]-[timestamp of group creation]@g.us`
* Broadcast Channels: `[timestamp of group creation]@broadcast`
But the bridge does currently interprets (and prints) the only second option.
This is half a fix for #874
This patch introduces a new config flag:
- MediaConvertTgs
These need to be treated independently from the existing
MediaConvertWebPToPNG flag because Tgs→WebP results in an
*animated* WebP, and the WebP→PNG converter can't handle
animated WebP files yet.
Furthermore, some platforms (like discord) don't even support
animated WebP files, so the user may want to fall back to
static PNGs (not APNGs).
The final reason why this is only half a fix is that this
introduces an external dependency, namely lottie, to be
installed like this:
$ pip3 install lottie cairosvg
This patch works by writing the tgs to a temporary file in /tmp,
calling lottie to convert it (this conversion may take several seconds!),
and then deleting the temporary file.
The temporary file is absolutely necessary, as lottie refuses to
work on non-seekable files.
If anyone comes up with a reasonable use case where /tmp is
unavailable, I can add yet another config option for that, if desired.
Telegram will bail out if the option is configured but lottie isn't found.
When there is a valid HTML formatting then remove this in the cleartext
field of the matrix client. This leads to nicer push messages on
smartphone apps.
Fix#1188
By default, gIRC rate limits all outgoing messages.
Since matterbridge already implements message throttling, this is extra layer of throttling is not necessary.
When a webhook "edits" a message, it does this by deleting the message
and creating a new one with the new content.
On creation of this new message, we'll get another ID then already is
know by the gateway in its id cache. So we add it in our own cache and
replace it whenever we want to edit/delete it again.
