redactions are not relayed to clients if the original event has been deleted (eg via message retention)

[Fred-Treebal]

On our mobile client, we use the redact WS (https://matrix.org/docs/spec/r0.0.1/client_server.html#put-matrix-client-api-r0-rooms-roomid-redact-eventid-txnid) when a user wants to remove one of his messages. It works fine for recent messages. But, in our matrix configuration, we use a short retention period of messages (7 days). When a user wants to delete a message older than 7 days (visible/cached on client but purged from the homeserver), it seems that the ‘redact’ WS does not trigger anything. No event of type m.room.redaction is sent to the mobile clients through the sync for the deleted event.

Could the deletion/redaction mechanism be made to work regardless of the homeserver retention period ?

[H-Shay]

I'm slightly confused here, you would like the option to redact events that have already been deleted from a homeserver but are still visible locally in the client? I think most clients give the option to delete the message locally-perhaps there is something I am missing here?

[ShadowJonathan]

(Note that that is a very old specification version, this version is more recent)

[Fred-Treebal]

I'm slightly confused here, you would like the option to redact events that have already been deleted from a homeserver but are still visible locally in the client? I think most clients give the option to delete the message locally-perhaps there is something I am missing here?

The idea would be to not only delete the msg locally but also on destination devices (to keep the same behaviour as a recent message deletion), if matrix relayed redaction events even on deleted events this would trigger a "normal" event deletion on receivers devices also.

[richvdh]

If matrix relayed redaction events even on deleted events

This is tricky. In order to stop people trying to redact other peoples' messages, Matrix servers deliberately withhold redaction events until the server has confirmed that the redaction is valid. This is specified in https://spec.matrix.org/v1.2/rooms/v3/#handling-redactions:

If the server would apply a redaction, the redaction event is also sent to clients. Otherwise, the server simply waits for a valid partner event to arrive where it can then re-check the above.

Unfortunately, message retention is something of an experimental feature, and bugs like this are to be expected.

[ShadowJonathan]

Unfortunately, message retention is something of an experimental feature, and bugs like this are to be expected.

Personally, I'd suggest then keeping this issue open, and allow it to provide feedback to MSC1763 & friends wrt possible sync extensions or other client-facing "nudges"

[anoadragon453]

@ShadowJonathan I would argue that such issues should be transferred back to the MSC as PR review comments? Such as "Synapse found this difficult to implement because of...".

As for this particular issue, MSC1763 (for which Synapse's message retention is an implementation of), tries to solve this problem by storing the retention periods in state. Clients are then expected to read this information and remove messages themselves, without the need for the homeserver to command a deletion for each message. There's also a boolean that controls whether clients should do this (in case messages are only deleted to save resources on the homeserver): expire_on_clients.