@ -198,12 +198,18 @@ The two cases where this is different is:
Servers tend to maintain a sliding window of events to deliver to other servers e.g the most recent 50 PDUs. Sticky events
can fall outside this range, which is what we define as "old". On the receiving server, old events appear to have unknown
`prev_events`, which cannot be connected to any known part of the room DAG. Sending sticky events to newly joined servers can be seen
as a form of sending old but unexpired sticky events, and so this proposal only considers this case. Sending these old events
will potentially increase the number of forward extremities in the room for the receiving server. This may impact state resolution
as a form of sending old but unexpired sticky events, and so this proposal only considers this case.
Servers MUST send old sticky events in the order they were created on the server (stream ordering / based on `origin_server_ts`).
This ensures that sticky events appear in roughly the right place in the timeline as servers use the arrival ordering to determine
an event's position in the timeline.
Sending these old events will potentially increase the number of forward extremities in the room for the receiving server. This may impact state resolution
performance if there are many forward extremities. Servers MAY send dummy events to remove forward extremities (Synapse has the
option to do this since 2019). Alternatively, servers MAY choose not to add old sticky events to their forward extremities, but
this A) reduces eventual delivery guarantees by reducing the frequency of transitive delivery of events, B) reduces the convergence
rate when implementing ephemeral maps (see "Addendum: Implementing an ephemeral map"), as that relies on servers referencing sticky events from other servers.
rate when implementing ephemeral maps (see "Addendum: Implementing an ephemeral map"), as that relies on servers referencing sticky
Kegan Dougal
2 months ago
committed by