| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Opportunistically preserve Slack threading when parent thread in cache. [#529]
* Removed slack-specific processing from gateway.
* Added docs.
* Add option to enable threading, with default to off.
* Did cleanup on @42wim's comments.
* Update gateway/gateway.go
Co-Authored-By: patcon <patrick.c.connolly@gmail.com>
* Suggestion from @42wim :)
* Suggestions from @42wim.
* More suggestions.
|
| |
|
|
|
|
| |
* When auto-loading envvars from toml keys, remove hyphens.
See: https://unix.stackexchange.com/questions/23659/can-shell-variable-include-character
|
| |
|
| |
fix #549
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add config option MediaUploadPath
MediaDownloadPath can be used instead of MediaServerUpload, for when your
webserver is on the same system as matterbridge and matterbridge has
write access to the serve dir.
* Limit length of hash in MediaServer urls to 8chars
Full SHA256 is unnecessary for uniqueness.
Also; if a file has the same first 8 charachters of the SHA256 hash,
it's still not a problem, as long as the filename is not the same.
|
| |
|
|
|
|
|
|
| |
* Colorize username sent to IRC using its crc32 IEEE checksum
* Add `ColorNicks` configuration variable
* Add `ColorNicks` setting
|
| | |
|
| | |
|
| |
|
|
| |
except connection and gateway configuration. Closes #373
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
mediaserver is configured. Closes #362
An extra avatarMap (cache) is created for mattermost and telegram.
If MediaServerUpload is configured, the avatar images of users are downloaded the first time a
user sends a message.
If this download succeeds a message with EVENT_AVATAR_DOWNLOAD is sent to the originating protocol.
This message also contains a SHA field (in msg.Extra["file"]), if this is not empty, the sha will
be added to the avatarMap. (so we now have a userid-sha cache)
Next time this user sends a message, the MediaServerUpload/sha/userid.png URL will be used as the
avatar field.
|
| | |
|
| | |
|
| |
|
|
| |
See #359
|
| |
|
|
| |
only from slack). Closes #353
|
| | |
|
| | |
|
| |
|
|
| |
(slack,telegram,matrix)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Add 2 extra options `MediaServerUpload` and `MediaServerDownload`, where
the URL for upload and download can be specified.
See https://github.com/42wim/matterbridge/wiki/Mediaserver-setup-%5Badvanced%5D
for an example with caddy
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Closes #255
Refactor message.Extra to a map[string][]interface{} to have a bit more flexibility
for stuffing extra stuff.
For attached files from slack, files < 1MB size get downloaded (in memory), and get
put into Extra["file"][]config.FileInfo (containing a pointer to the buffer and
the filename). This is not async so slack channels with lots of attached files
may suffer a slowdown. (the download timeout is set at 5 seconds).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently fully support mattermost,slack and discord.
Message deleted on the bridge or received from other bridges will be
deleted.
Partially support for Gitter.
Gitter bridge will delete messages received from other bridges.
But if you delete a message on gitter, this deletion will not be sent to
other bridges (this is a gitter API limitation, it doesn't propogate edits
or deletes via the API)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our Message type has an extra ID field which contains the message ID of the specific bridge.
The Send() function has been modified to return a msg ID (after the message to that specific
bridge has been created).
There is a lru cache of 5000 entries (message IDs). All in memory, so editing messages
will only work for messages the bot has seen.
Currently we go out from the idea that every message ID is unique, so we don't keep
the ID separate for each bridge. (we do for each gateway though)
If there's a new message from a bridge, we put that message ID in the LRU cache as key
and the []*BrMsgID as value (this slice contains the message ID's of each bridge that
received the new message)
If there's a new message and this message ID already exists in the cache, it must be
an updated message. The value from the cache gets checked for each bridge and if there
is a message ID for this bridge, the ID will be added to the Message{} sent to that
bridge. If the bridge sees that the ID isn't empty, it'll know it has to update the
message with that specific ID instead of creating a new message.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
