Synapse does not bundle `m.replace` aggregations for events other than `m.room.message`

[richvdh]

Per MSC2675, when the server returns an event, it is supposed to bundle the aggregation of any related events into the response.

This includes m.replace relations: for an m.room.message event, /context/$original_event_id might return:

{
  "event": {
    ...
    "event_id": "$original_event_id",
    "type": "m.room.message",
    "unsigned": {
      "m.relations": {
        "m.replace": {
          "event_id": "$replacement_event_id",
          "origin_server_ts": 1650390324643,
          "sender": "@richvdh:matrix.org"
        }
      }
    },
    "user_id": "@richvdh:matrix.org"
  }
}

However, for other event types, no m.replace aggregation is returned.

It's not as if m.room.message is the only event type you can edit (consider, for example, encrypted events), so this seems odd.

[richvdh]

Presumably this means that if you forward-paginate through a room with /messages and get as far as the updated event, you'll see the old content rather than the edited content.

[clokep]

Presumably this means that if you forward-paginate through a room with /messages and get as far as the updated event, you'll see the old content rather than the edited content.

Another situation this can impact clients is when viewing a thread (which uses the /relations API). @t3chguy mentioned to me that clients essentially assume all encrypted events have an edit and attempt to re-fetch them from the server to see if this is accurate. (matrix-js-sdk is using /relations to see if there are edits, see https://github.com/matrix-org/matrix-js-sdk/blob/v17.1.0-rc.1/src/models/thread.ts#L240.)

See also element-hq/element-web#21447 and element-hq/element-web#21445

[richvdh]

@t3chguy mentioned to me that clients essentially assume all encrypted events have an edit and attempt to re-fetch them from the server to see if this is accurate.

so to be clear: that is a workaround for this bug, and if we fixed this bug, clients could remove that workaround?

[clokep]

@t3chguy mentioned to me that clients essentially assume all encrypted events have an edit and attempt to re-fetch them from the server to see if this is accurate.

so to be clear: that is a workaround for this bug, and if we fixed this bug, clients could remove that workaround?

This is my understanding, yes. 👍

[t3chguy]

Yes, once enough server uptake EW will gladly remove the check which asks the server for /relations on each and every thread response