* 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.
This pull request properly sets the events EventJoinLeave and EventTopicChange for messages from the RocketChat bridge and drops messages which are neither one of those events nor plain messages.
* move stripCustomoji logic to default Tengo script
Removing the image ID from the message (without any possibility of recovering it later) is a loss of valuable data that prevents users from giving support to custom emoji via Tengo scripts.
* bugfix - do send colors to other irc bridges
"if we're not sending to an irc bridge we strip the IRC colors"
Co-authored-by: c0ncord <59654954+c0ncord@users.noreply.github.com>
Fail if:
* we don't have any gateways configured
* we have gateways configured but with non-existing bridge configuration
* we have gateways configured without any configuration
* initial work on native keybase bridging
* Hopefully make a functional keybase bridge
* add keybase to bridgemap
* send to right channel, try to figure out received msgs
* add account and userid
* i am a Dam Fool
* Fix formatting for messages, handle /me
* update vendors, ran golint and goimports
* move handlers to handlers.go, clean up unused config options
* add sample config, fix inconsistent remote nick handling
* Update readme with keybase links
* Resolve fixmie errors
* Error -> Errorf
* fix linting errors in go.mod and go.sum
* explicitly join channels, ignore messages from non-specified channels
* check that team names match before bridging message
This adds support for the discord category option that can be used
to group channels in. This means we can have multiple channels with
the same name.
We add the option to specify a category in the channel option of a
discord account under [[gateway]]
Besides channel="channel" or channel="ID:channelID", now also
channel="category/channel" can be specified.
This change remains backwards compatible with people that haven't
specified the category and incorporates the fix in #861
* Support webhook message deletions (discord)
Messages sent via webhook can now be deleted. It seems it can do this
without any special permissions.
This copies discordgo.WebhookExecute and makes it support the returning
of discordgo.Message.
A pull request has been sent upstream, so we should use that if
@bwmariin accepts the pull request:
https://github.com/bwmarrin/discordgo/pull/663
Changes in behaviour (webhook mode only):
- Previously messages *edited* on other platforms would just be
retransmitted as a brand new message to Discord.
- Message *edits* will now be ignored.
- Debug: message edits will now print out a "permission error".
In the future it may be good to send an "message edited" react to those
webhook messages, so at least people know that the message was edited on
other platforms. (Even though it can't actually show the new message.)
Alternatively, message edits could just send a brand new message with a
link back to the old one. This is a little ugly but it would ensure that
Discord users are able to see the edited message. These "message edit
notifications" would be sent from the bot user (not from a webhook), so
we could edit the "edit notification" if subsequent edits to the
original message are made.
Actually check if we're connected when trying to Send() a message.
Messages now will get dropped when not connected.
TODO: Ideally this should be in a ring buffer to retransmit when the
connection comes back up.
