|
|
|
@ -195,7 +195,7 @@ given event (for example, if an event is edited multiple times). These should
|
|
|
|
be [aggregated](#aggregations-of-child-events) by the homeserver.
|
|
|
|
be [aggregated](#aggregations-of-child-events) by the homeserver.
|
|
|
|
|
|
|
|
|
|
|
|
The aggregation format of `m.replace` relationships gives the **most recent**
|
|
|
|
The aggregation format of `m.replace` relationships gives the **most recent**
|
|
|
|
replacement event, formatted [as normal](#room-event-format).
|
|
|
|
valid replacement event, formatted [as normal](#room-event-format).
|
|
|
|
|
|
|
|
|
|
|
|
The most recent event is determined by comparing `origin_server_ts`; if two or
|
|
|
|
The most recent event is determined by comparing `origin_server_ts`; if two or
|
|
|
|
more replacement events have identical `origin_server_ts`, the event with the
|
|
|
|
more replacement events have identical `origin_server_ts`, the event with the
|
|
|
|
@ -268,6 +268,11 @@ Client authors are reminded to take note of the requirements for [Validity of
|
|
|
|
replacement events](#validity-of-replacement-events), and to ignore any
|
|
|
|
replacement events](#validity-of-replacement-events), and to ignore any
|
|
|
|
invalid replacement events that are received.
|
|
|
|
invalid replacement events that are received.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Clients should render the content of the **most recent** valid replacement event. The
|
|
|
|
|
|
|
|
most recent event is determined by comparing `origin_server_ts`; if two or more
|
|
|
|
|
|
|
|
replacement events have identical `origin_server_ts`, the event with the
|
|
|
|
|
|
|
|
lexicographically largest `event_id` is treated as more recent.
|
|
|
|
|
|
|
|
|
|
|
|
##### Permalinks
|
|
|
|
##### Permalinks
|
|
|
|
|
|
|
|
|
|
|
|
When creating [links](/appendices/#uris) to events (also known as permalinks),
|
|
|
|
When creating [links](/appendices/#uris) to events (also known as permalinks),
|
|
|
|
|