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

[clokep]

See #14252.

[clokep]

@richvdh I guess we might be able to re-land this once MSC3925 becomes generally available? Otherwise, the support for that might be lacking as-is.

[richvdh]

@richvdh I guess we might be able to re-land this once MSC3925 becomes generally available?

That is my hope, yes!

[clokep]

@richvdh I guess we might be able to re-land this once MSC3925 becomes generally available?

That is my hope, yes!

We've now merged #15193, so we can probably try this again soon.

[clokep]

@richvdh I guess we might be able to re-land this once MSC3925 becomes generally available?

That is my hope, yes!

We've now merged #15193, so we can probably try this again soon.

The changes in #15193 just shipped this week (in v1.79.0). I haven't seen any reports of regression due to it, but to be safe I think we should likely wait until v1.81 before making this change.