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.
Adds a new key OutMessage under [tengo] table, which specifies the location of the script that
will be invoked on each message being sent to a bridge and can be used to modify the Username
and the Text of that message.
The script will have the following global variables:
read-only:
inAccount, inProtocol, inChannel, inGateway
outAccount, outProtocol, outChannel, outGateway
read-write:
msgText, msgUsername
The script is reloaded on every message, so you can modify the script on the fly.
The default script in https://github.com/42wim/matterbridge/tree/master/internal/tengo/outmessage.tengo
is compiled in and will be executed if no script is specified.
This commit add support for using the result of a tengo script in RemoteNickFormat using {TENGO}
Also adds a new toml table [tengo] with key RemoteNickFormat and value location of the script.
This also moves the TengoModifyMessage from [general] to Message in [tengo]
Documentation:
RemoteNickFormat allows you to specify the location of a tengo (https://github.com/d5/tengo/) script.
The script will have the following global variables:
to modify: result
to read: channel, bridge, gateway, protocol, nick
The result will be set in {TENGO} in the RemoteNickFormat key of every bridge where {TENGO} is specified
The script is reloaded on every message, so you can modify the script on the fly.
Example script can be found in https://github.com/42wim/matterbridge/tree/master/contrib/remotenickformat.tengo
[tengo]
RemoteNickFormat="remotenickformat.tengo"
Revert "Fix typo"
This reverts commit dffd67eb31.
Revert "Handle quit message relay better on gateways with one channel on the irc bridge #722"
This reverts commit 240559581a.
Revert "Support quits from irc correctly. Fixes#722 (#724)"
This reverts commit d76a04bd0a.
For an unknown reason we get duplicate messages (from the same channel)
using the realtime API when we have > 1 channel subscribed on.
Solution for now is caching the message ID in a LRU cache and ignoring
the duplicates.
This should be reviewed when we have actual editing support from the
realtime API
Breaking change for zulip channel configuration.
For zulip the channel configuration will now need to specify also
the topic with /topic:yourtopic.
Example:
[[gateway.inout]]
account="zulip.streamchat"
channel="general/topic:mytopic"
This fixes the incorrect PR #701 which didn't work with multiple
gateways.
* Add MediaConvertWebPToPNG option (telegram).
When enabled matterbridge will convert .webp files to .png files
before uploading them to the mediaserver of the other bridges.
Fixes#398
This checks if we get a topic change < 5 seconds after connection.
If that's the case, ignore it.
Also this PR makes the topic change an actual EventTopicChange.
* Add support for editing/deleting messages
* Add support for uploading files
* Add support for avatars
* Use the Rocket.Chat.Go.SDK
* Use the rest and streaming api
* Add support for editing/deleting messages
* Add support for uploading files
* Add support for avatars
* Use the Rocket.Chat.Go.SDK
* Use the rest and streaming api
Stop getting users if we reach 2000 users. Slack will rate-limit us
even if we follow their limits.
This means that we now have to lookup every user that says a message
for the first time. This should be less intensive on the API.
This also disables partly fb713ed91b for now.
ChannelMembers will not be filled.
* Add initial support for getting ChannelMember info of all bridges.
Adds an EventGetChannelMembers event, which gets send every x time to
all bridges. Bridges should respond on this event with a Message
containing ChannelMembers in the EventGetChannelMembers key in the
Extra field.
handleEventGetChannelMembers will handle this Message and sets the
contained ChannelMembers to the Bridge struct.
* Add ChannelMembers support to the slack bridge
This uses our own gomatrix lib with the SendHTML function which
adds HTML to formatted_body in matrix.
golang-commonmark is used to convert markdown into valid HTML.
* SSH-Chat: set quiet mode to filter joins/quits
* SSH-Chat: Trim newlines in the end of relayed messages
* SSH-Chat: fix media links
* SSH-Chat: do not relay "Rate limiting is in effect" message
When setting wait to true, we wait until the populating isn't in progress anymore.
This is used on startup connections where we really need the initial information
which could take a long time on big servers.
If IRC connection fails on first connect, bail out.
Wait until after nickserv auth until joining channels (also after reconnects)
Don't do a separate irc timeout, some connections take a while #503
