[General] Support thread/reply preservation

[patcon]

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

• Discord
  • no threads, but now supports replies.
    • h/t @nicolas17 (see [General] Support thread/reply preservation #638 (comment))
    • webhooks do not support replies
    • UPDATE: now has threads! h/t @locness3
• Gitter (see below)
• Matrix/Riot (no threads, but has replies)
  • no has threads (api docs) h/t @ys-chung @locness3
• Mattermost Add support for mattermost threading #627
• RocketChat (see below)
• Slack Opportunistically preserve threading between Slack instances #529
• XMPP (spec supports)
• Zulip (see below)
• MS Team [General] Support thread/reply preservation #638 (comment) (has thread. api docs)
  • @colpari offered a potential commission for this work! MSTeams support for bridging chats #1838 (comment)
  • code spike: MSTeams threading #1240

Related: issue on persistent cache so more durable rethreading #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 (RocketChat/Rocket.Chat#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: RocketChat/Rocket.Chat#1112 (comment)

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 :)

[ys-chung]

Discord announced threads will launch tomorrow.

[qstambaugh]

At the very least, on the XMPP side, would we be able to get the message that's being replied to in a quote above the message? Example:

> Message being replied to as a quote instead
The new message that's a reply to the quoted message above

If someone is replying to a message on Discord or Matrix, it just shows the new message on XMPP with no indication that it's a reply or anything.

[glasgowm148]

Bumping this as Discord replies are lacking and probably the most needed feature on that platform as it makes the Discord side ugly and hard to read. I'm aware webhooks do not support replies, (discussion here) but there seems to be another implementation that handles them a bit better.

The Connections Bot uses buttons instead and looks cleaner:

[locness3]

Please edit the original message to consider Discord and Matrix's new support for threads.

[unode]

Matrix to Mattermost threads are working but Mattermost to Matrix messages are posted off-thread.

Does anyone know if additional configuration is required to have symmetric support for this feature or if it's simply not implemented yet?

[patcon]

Thanks @locness3 @ys-chung -- updated the original message about discord and matrix threads!

@unode Sorry, not sure about bidirectional threading, but each direction is implemented separately -- incoming and outgoing need to be working. Someone may have gotten one direction working, without the other being done. You'll need to look into it, or maybe create a new issue if you think it's a regression (that it worked before).

[patcon]

Added mention and links to MSTeam code stub too