Forwarding a message should show who it was from

[Qwertie-]

The current forward message system is a little useless. Instead of just copying the message it should have a header with who it was from.

For example If I send a message "I'll be there in an hour"
when someone forwards it it should say

Forwarded message from Qwertie- [13:32]:
I'll be there in an hour

Ideally the username would be one of those new clickable pills and the time substituted with when the message was sent in the viewers local time (Maybe send it as UTC and have the client change it to the local time zone).

[t3chguy]

This was my intention but the best way to do this is with a spec extension/change

[t3chguy]

(because you can't just prepend some text to an image file etc)

[Qwertie-]

Ah yeah fair enough. Surely its a quick change to get it in just on text messages though?

[t3chguy]

Spec changes are never quick sadly, but it is a simple one

[ananace]

Perhaps this could be done in a similar manner as the reply system?

# ...
    "m.relates_to": {
      "m.forwarded_from": {
        "event_id": "$1534534810511408ubhty:matrix.org"
      }
    },
# ...

Or something like that? With the whole <mx-reply> block and all

[t3chguy]

@ananace I agree, though notes:

• it'd require a room_id also

but I don't agree that the <mx-reply> thing should be added at all, that's a fallback thing for replies.
Adding it would mean you couldn't forward images/files which for me at least is the primary use of forwarding (saves me having to download and re-upload media)

[ananace]

I phrased that particular part of the comment rather poorly I now realize, I meant that as related to the "as the reply system" example.

For the forward it would probably be better to have something forward-specific, though I still think it would be helpful to provide some kind of wrapping for at least non-content messages. (m.text, m.notify, m.emote)

I'm curious though, I though the reply system would work for replying to images? And in that case it must use the <mx-reply> block at least in some form, right? Without requiring you to upload a copy of the image you're replying to.

[t3chguy]

@ananace it does not work for replying to/with files/media because of the current need for a fallback. The reply system, ignoring the fallback, does work with files/media otherwise.

[eMPee584]

Uhm ... p3?
how about implementing a workaround in the meantime?

[t3chguy]

It is not possible to implement a workaround for files/media/images so it'd cause an inconsistency

[eMPee584]

Pardon me again: seriously, this can not be P3.. it opens room to quite severe misinterpretations.. Please implement a work-around for text-messages at least, an inconsistency for a couple of months is better than the current state..

[Qwertie-]

The feature should really be removed until this can be fixed. Not only is it not useful in the current state, its basically a trap for users who don't know it doesn't work.

[t3chguy]

The feature should really be removed until this can be fixed. Not only is it not useful in the current state, its basically a trap for users who don't know it doesn't work.

I may be biased as I wrote the feature way back when, but my primary use of it is forwarding media without having to download and re-upload it (which can potentially take minutes on slow connections) which I would deem quite useful. Yes I agree that forwarded things should be clearly marked, but doing it in a hacky way would be a bad time, if this doesn't get picked up in the summer then I will write an MSC for it.

[tulir]

There are now two proposals for this: matrix-org/matrix-spec-proposals#2723 and matrix-org/matrix-spec-proposals#2730

[bjherbison]

Until this is implemented I would like the option to prevent "Forward Message" from being shown in the UI. The current version is so disrespectful to the original author that I never want to use it accidentally.

[HarHarLinks]

I want this feature in element (matrix) but I think it may need some nuances.

1. forward a message by "rich embedding" it similar to how replies quote a message. maybe this should only work if the other person can see the original message (is in the originating room, or the room is public, space join, ...) and leak as little metadata as possible.
2. forward by "reposting" is the other side of the coin and might be just as useful.

Here are my thoughts from feature request element-hq/element-web#18190, that focus on a certain part of this more general feature. In particular I want to be able to at least comment on the forwarded (variant 1) message similar to how replies work.

---

Is your suggestion related to a problem? Please describe.

I happens regularly for me that someone is confused about what message is being discussed, because they missed it or similar.
We can currently permalink to a message by "sharing" it via the context menu to get a matrix.to link. Clicking that link stays within riot and, if the room/message is accessible to the client, will navigate to it.

This is fine but it could be nicer.

Describe the solution you'd like.

I would like a way to render such matrix.to links to messages similarly to a reply. You could think of my UI vision like a custom embedded reply. This is somewhat analogous to matrix.to user/room/community which are element's code for (try-to-make-)pill-here (is that even spec'd? something should get spec'd for that).

There should be a nice UI button that places the "embed code" in the composer for me, similar to the quote (and some extent reply) button. Perhaps the same action should add a relates_to field, which could be the same as the rich forwarding if that ever happens.
The UI for recipients should fall back to "this message is not accessible, because..." and probably the raw URL.

[Sazu-bit]

Is there any chance of an update on this issue it's been five years and it has legal implications not just for users, but chat moderators.

As per element-hq/element-web#24096 we don't actually need anything "major" but we need a quick and dirty fix to the problem. Even if it doesn't look pretty and just includes a name or reference back to the previous post.

There's no need to wait for the spec. Either there's a need to include original author data which appears to be stripped by element-hq/element-web#7929 or the feature should be disabled (see #884).