| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
| |
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
|
| |
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
GetChannelId will support names generated from query groups when a team is not set,
but not when a team is set since it falls through to getChannelIdTeam which has a different inner loop. i
This pull makes the two implementations do the same thing.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Needed for #872
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| | |
|
| |
|
|
|
|
| |
(#858)
Besides the bound checking, this now also use utf16 as suggested by
https://github.com/go-telegram-bot-api/telegram-bot-api/issues/231
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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 SkipVersionCheck bool option for mattermost
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Partially fixes #820.
A full fix requires patching https://github.com/matterbridge/go-xmpp to use DNS SRV records.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Fixes issue #814.
This is a somewhat hacky way of achieving the required goal but it seems
like this is the least problematic way of getting there.
We might want to redesign some bridge information later such that we
have a standardised way of specifying what is and what isn't supported
by each chat protocol / bridge.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
