search

matrix-org / matrix-appservice-discord

A bridge between Matrix and Discord.
Apache License 2.0
791 stars 148 forks source link

Add external_url to messages bridged from Discord to Matrix #837

Open Miepee opened 1 year ago

Miepee commented 1 year ago

Is your feature request related to a problem? Please describe. Matrix has an optional external_url tag (documentation), which can be used to indicate where the message came from. It would be nice if this bridge would send those as well

Describe the solution you'd like Send the discord message link when bridging them to Matrix. I.e.

{
    "content": {
        "body": "Hi",
        "format": "org.matrix.custom.html",
        "formatted_body": "Hi",
        "external_url": "https://discord.com/channels/<guildID>/<channelID>/<messageID>"
        "msgtype": "m.text"
    },
 [...]
}
SethFalco commented 1 year ago

One thing to consider here is how to handle messages with attachments.

Currently, messages with attachments have the external_url which points to the direct download URL to the asset from Discord servers.

If we want normal messages to include it too, then in the case of attachments, should it point to the attachment or the message containing the attachment?

Miepee commented 1 year ago

Good question, I personally don't have any preference there.

SethFalco commented 1 year ago

I don't have a strong preference either, though I can say that from my experience, having the attachment URL has helped me. For example, in https://github.com/matrix-org/matrix-appservice-discord/issues/857 I was able to access a video that failed to cross the bridge, thanks to the external_url.

However, I'm partial to judge based on that alone since that was just a bug.

Reviewing it outside of that, using the attachment URL might make sense since it's actually accessible to users that don't have a Discord account. Meanwhile, using the message URL might make more sense since it offers consistency between all bridged messages.

For now, I'd probably favor leaving it with the attachment URL since it is viable, and it's the current implementation anyway so might as well keep the same behavior it had before, I guess. 🤔