Specify a means for clients to "edit" previous messages (SPEC-410)

[matrixbot]

Submitted by @​matthew:matrix.org

(Imported from https://matrix.org/jira/browse/SPEC-410)

[matrixbot]

Jira watchers: @leonerd @richvdh

[matrixbot]

Links exported from Jira:

relates to SPEC-9
vector-web matrix-org/matrix-spec-proposals#1862

[matrixbot]

As with redactions, this will presumably take the form of an event which refers to the original event.

-- @richvdh

[matrixbot]

Since Gitter has the ability to perform message updates (it lets users edit their most recent message) the Matrix-Gitter bridge has to handle this. Currently it does it by performing a diff between the old and new content, stripping a common prefix and suffix and then presenting the resulting change on the Matrix side in a (somewhat) helpful way. I've made mention of this spec bug in the code there, so if a better means arrives in Matrix to represent this it can be updated.

See
matrix-org/matrix-appservice-gitter@0760134

-- @leonerd

[matrixbot]

Pretty, pretty please with sugar on top add this soon.

-- Andrew

[enyo]

Is there a branch or a PR regarding this issue where we could follow implementation of this issue?
This is the last feature that I think is really severely missing from matrix.

[ara4n]

there's a contribution from @pik at matrix-org/matrix-react-sdk#588 but we haven't yet got to properly review or merge it, as the core team is drowning in E2E bughunting etc. Agreed that it's a hugely important feature.

[MurzNN]

Maybe in near future you will have time to review this contribution? Edit message feature will be very useful for people, especially for blog-like rooms via Matrix Live or Journal

[NotAFile]

Some discussion with @richvdh revealed the following:

• You can not naively edit matrix messages, since messages are identified by their HMAC. Changing the message thus invalidates it. This means that the only way to implement editing is to send a second event.

• You can not naively send an edit event, as it might be missed by the client and homeserver. This would happen e.g. when permalinking to an old message that was edited later.

There appear to be three solutions:

• message aggregation: I have no idea what this means or entails, but it was mentioned. This is apparently a difficult solution that also enables reactions and slack-style threading.

• Limiting the amount of time/messages between a message and an edit and forcing the homeserver to backfetch those messages. While hardly elegant, this is a simple solution. Since most messages are edited immediately after sending, it should work quite well.

• Invalidating the original event with a link to the current one. This seems like the most promising solution to me. The original event is pseudo-redacted and a new attribute, e.g. "superseded_by" or "edited" is added with a link to the replacement event. This means the HMAC would no longer match, but this is fine because the new event has a valid HMAC.

If no objections are made, I hope to make a proposal for implementing the last solution soon.

Other issues:

• privacy vs transparency: while a message edit history is nice, users might expect edits to destroy the previous message, which is unfortunate if it contains accidentally shared information.

• several edits: The easiest way here would be the server redacting the previous edit event when another edit is made

• Bridged protocols without support for message editing. When bridging to e.g. IRC, there is no good way to deal with edits. Sending a new message for a one letter typo fix is bound to annoy other users, while not relaying an edit might lead to miscommunication

[romainf-unity]

Hope I'm not intruding here. I've read your very interesting post @NotAFile and that made me thinking.

Disclaimer: I'm merely proposing a solution from my perspective, hoping it's also what most of the users would like to have as well. Although I'm a programmer myself, I reckon I don't know anything about decentralized messaging apps 😄

From a user perspective, I think the user should have all the rights over his messages. And by that, I think this is what Matrix should be aiming to. Of course, there is always the problem of a third party server that don't follow the protocol and, for instance, keeps all the versions of the messages, even if the user asked to delete it... but we can't do anything against that, can we?

So, with that in mind, I think a solution could be to see the history of the messages. This is helpful for both the author of the message, but also the other users that can see what has been edited (that would actually be a feature Slack doesn't have).

By being able to see the history of his message, the user will understand that editing the message simply adds a new "revision" to the message, but if he wants to delete the message entirely, he'll have to delete his message (with a confirmation window, showing that this is "more permanent" than a simple edit).

[MurzNN]

I support proposal for editing message via adds new revision (like comments in Facebook)- this will be best way. Maybe this can be implemented via Threaded Messaging feature, with special mark that this is thread for message revision, and display only last revision for this thread type.