Support Discord Reply (fix #43)

[lekoOwO]

Fixes #43

[selfhoster1312]

Hello, thanks for submitting this PR here.

I'm not yet very familiar how the reply system works, but i know it uses properties and methods on config.Message: Message.Parent and Message.ParentValid() notably. If you have time to dig around and experiment, that's great!

Editing rmsg.Text is definitely a hacky solution that will prevent interoperability with other protocols, because the other protocol won't know it's a reply and format it properly. I mean i say another protocol, but you could observe it between two discord channels for examples.

I'm sorry it's not well documented yet. This is an area we haven't touched since forking, we've been more focused on file attachments for the moment.

[selfhoster1312]

This is a blocking network request, and should not be performed on the main thread (because it will block processing other events if the discord API takes some time). There's many ways to work around that. One would be instead of returning string from the method, you could return a boolean indicating whether the method is in fact handling a reply:

• if it is, just ignore it in the createMessage method, and start a new goroutine in handleQuote
• if it's not, keep going with the original msg

[selfhoster1312]

An alternative could be to store the last ~100 messages or so per channel, so we don't have to do a network query at all.

[kousu]

Oh I just noticed this! This contrasts with #135 and #134. I assume you run a bridge that doesn't support reply tags, like IRC or Mumble. I mostly use XMPP though so I want the direct opposite approach.

• Discord -> IRC bridging: add a quote in msg.Text
• XMPP -> Discord: strip quotes from msg.Text

I don't want Discord -> XMPP to add quotes, they'll be messy and redundant for my case.

I wonder if the reply system needs to reworked at gateway/gateway.go level. It would be cleaner if the incoming bridge handled parsing the reply tag into Message.ParentID and separating message (message.Text) from quote (currently not stored), while the outgoing bridge could decide whether to translate Message.ParentID into its native reply tag format and whether to glue Message.Text back together with the quote. There's nowhere to separate quote text at the moment, so that would have to be added.

[poVoq]

I wonder if the reply system needs to reworked at gateway/gateway.go level. It would be cleaner if the incoming bridge handled parsing the reply tag into Message.ParentID and separating message (message.Text) from quote (currently not stored), while the outgoing bridge could decide whether to translate Message.ParentID into its native reply tag format and whether to glue Message.Text back together with the quote. There's nowhere to separate quote text at the moment, so that would have to be added.

If you want to give it a shot, that would certainly be appreciated. I guess in the mean-time we could merge this as a temporary solution?

[kousu]

If you want to give it a shot, that would certainly be appreciated

Okay thanks for the vote of confidence in that direction :)

I guess in the mean-time we could merge this as a temporary solution?

For what it's worth, I vote yes, keep the improvements coming ! It's crazy that the fix stalled out for 4 years.

[poVoq]

Thanks!

[selfhoster1312]

I guess in the mean-time we could merge this as a temporary solution?

That's reasonable. I opened #142 to track implementation of a new replies system.

In the meantime, if there are any breaking changes in this PR, can someone who understands them (i.e. someone who uses Discord) open a new PR to update the changelog?

EDIT: of course if there are no breaking changes, a changelog entry is more than welcome anyway, just not in the "breaking changes" section

[kousu]

In the meantime, if there are any breaking changes in this PR, can someone who understands them (i.e. someone who uses Discord) open a new PR to update the changelog?

I built and deployed (for ref: from) with this patch in. Just rebooting led to this duplication, which I expected:

The quote box is the <reply> from #134, and the "@kousu: XMPP" is from this PR, redundantly. Any bridge that understands replies natively is going to do the same thing unless someone sets QuoteDisable=true, so that's probably worth a note in the changelog: #144

[selfhoster1312]

I'll trust your judgement on whether this should be the default behavior or not (it's not too late to make a new PR to disable it by default) :)