Matterbridge: [General] Support thread/reply preservation

[patcon]

Just adding a place to track details for threading support across protocols.

• [ ] Discord
  
  
  
  • no threads, but has quotes now supports replies.
  
  
  • h/t @nicolas17 (see https://github.com/42wim/matterbridge/issues/638#issuecomment-731441216)
  
  
  • webhooks do not support replies
  
  
• [ ] Gitter (see below)
• [ ] Matrix/Riot (no threads, but has replies)
• [ ] Mattermost #627
• [ ] RocketChat (see below)
• [x] Slack #529
• [ ] XMPP (spec supports)
• [ ] Zulip (see below)
• [ ] MS Team https://github.com/42wim/matterbridge/issues/638#issuecomment-747363365

Related: issue on persistent cache so more durable rethreading https://github.com/42wim/matterbridge/issues/541

Slack

Done.

Mattermost

TBD.

Zulip

Should be possible to support threading on "topics", which can perhaps be considered ParentID's:
https://zulipchat.com/api/send-message

From update message docs:

• msg's can have no topic(parentID)
• anyone can add topics(parentIDs) to messages that don't have them (this might be awkward), so essentially anyone can thread a message that's already in main channel
• admins and msg owners can change topics(parentIDs). this essentially means that they can rethread messages into main channel, and even into other threads.
  
  
  
  • there is also something to do with propagate_mode, which means a rethread can bring either 1) just itself, 2) all messages in thread, or 3) just itself and messages after.
  
  

For brings messages from Slack/Mattermost, which have a similar thread paradigm. Would need to either fake a "topic" based on ThreadTimestamp/ParentID (easiest), or somehow resolve a human-readable topic from the thread parent -- perhaps by pulling first 55 chars from parent, and then a 5 char nonce (for the 60 max). If doing the latter, then each threaded message going to zulip would need either 1) a Slack API call to get the msg content of parent, or 2) have all parent message content cached somehow, so looking up the human-readable topic is easy. Edits to the thread parent might affect this, so might need to watch that.

Obviously, generating a topic from the unchanging thread parent id is much simpler :)

This all seems theoretically doable, but could be a bit funny, and someone who really cares about zulip will probably have to be the one to sort out the edge-cases :)

RocketChat

Technically, there is not support (https://github.com/RocketChat/Rocket.Chat/issues/1112), but they are using attachments to signify replies:
https://rocket.chat/docs/user-guides/messaging/#replying-to-a-message

Some more implementation details seem to be here, if up-to-date: https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-434854294

For slack, we could use that to thread in slack, esp since if you say a new message is in reply to any message in a thread, Slack resolve the parent from that.

Gitter

No threading, nor real reply feature. But messages have direct links derived from msg ID, so that could be used in either direction, with some bit of lossiness whether to point to thread parent or thread message immediately preceding. This would be messy.

[nylen]

For Discord (and other platforms that support message editing), it seems like it would be possible to edit thread replies into the original message.

[42wim]

Discord has no threads. normal message editing already works

[nylen]

Yes, I know. I'm suggesting that for Discord, it would be possible to simulate threads by re-using the original message.

Example:

This is a message in Discord

After a reply in a Slack thread, the same single message would look like this:

This is a message in Discord

[Thread] This is a thread reply

This would preserve the context of the thread in what seems to me like a natural way.

[Helcaraxan]

Although I understand where you are coming from with the threading not being carried over I don't think that the proposed solution achieves what you really want for both UX and technical reasons:

• Technically there are limits to message lengths in Discord. Which means long running threads will become problematic.
• From a pure UX perspective imagine that you are in Discord and observing a thread being created from Slack.
  
  
  
  • Now if you reply to it your response will be in Discord below the thread-edited message.
  
  
  • In Slack it will also be coming in as a fresh message as there is no way of knowing it was a reply to the thread.
  
  
  • If a thread participant on Slack notices your messages:
    
    
    
    
    
    • They can reply in the thread on Slack which in Discord will appear _above_ your message, which is really strange and unpleasant UX.
    
    
    
    • They can reply with a normal Slack message or start a new Slack thread on your message, which means your mechanic is destroying the logic behind Slack threads rendering them completely useless.
    
    
    
  
  

The later scenario is already the case nowadays because of the lack of an ability to recognise a Discord message as being targeted at a particular thread but it is not solved by this solution either.

As a side-note: I don't think that something like Matterbridge works well in bridging between threaded and non-threaded platforms, unless you mimic threading near-perfectly in the non-threaded one you will encounter issues.

[nylen]

I don't think that the proposed solution achieves what you really want for both UX and technical reasons ... I don't think that something like Matterbridge works well in bridging between threaded and non-threaded platforms

Good points, I agree with you now.

[nylen]

Another idea for Discord: prefix [thread] to the message text when copying a threaded message from Slack. This at least makes it clearer that there is additional context to the message.

I have working code for this if there's interest.

[patcon]

Heh #557 :)

[nylen]

Here's what I came up with, for Discord only:

diff --git a/bridge/discord/discord.go b/bridge/discord/discord.go
index a9c508c..08e45ac 100644
--- a/bridge/discord/discord.go
+++ b/bridge/discord/discord.go
@@ -152,6 +152,13 @@ func (b *Bdiscord) Send(msg config.Message) (string, error) {
        msg.Text = "_" + msg.Text + "_"
    }

+   if msg.ParentID != "" {
+       // This message is part of a thread
+       // Note: For this to work, `PreserveThreading` must be set to True on
+       // the [discord.servername] config block
+       msg.Text = "[thread] " + msg.Text
+   }
+
    // use initial webhook configured for the entire Discord account
    isGlobalWebhook := true
    wID := b.webhookID

[ForsakenHarmony]

Is there currently any way to know if a message is coming from a thread? Just posting them in i.e. discord with 0 context is very confusing, I was wondering if there was a message that got deleted from the source slack at first

[wvffle]

Telegram also supports replies

[nicolas17]

Discord now has replies.

[patcon]

thanks @nicolas17! Updated issue body with ref

[alex88]

Are you planning on supporting MS teams as well?

[patcon]

Heh not really sure I'd call these "plans", since I'm not working on anything here atm, but I added your suggestion to the checklist for tracking :)

EDIT: but I did work on this project in the past :) I learned Golang for contributing, and I'm a total rookie. It's not hard to pick up though, and happy to jump on a call to talk through it with you, if you'd like to take a run at this :)