You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Aggregation events (edits, reactions) aren't well ordered in the timeline: we don't really know how to order them relative to each other. In the general case, it won't be a problem, but it might lead to discrepancies in a few cases:
when we have a bundled edit, for instance, right now we'll always prefer it to a pending edit. This might be wrong if the pending edit is more up-to-date than the bundled edit (i.e. the related pending edit is after the bundled edit event, in the overall ordering).
when we already have a pending edit and another comes in, we do some best-effort guessing if the new pending edit overrides the previous one or would be overridden by the previous one.
Ideally, the protocol would give us some perfect ordering over events, so we don't have to do any kind of guessing / rejiggering ourselves, e.g. with something akin to MSC4033. Otherwise, we may be able to use the all_events internal ordering (or the ordering provided by the Event cache, in some future).
The text was updated successfully, but these errors were encountered:
Aggregation events (edits, reactions) aren't well ordered in the timeline: we don't really know how to order them relative to each other. In the general case, it won't be a problem, but it might lead to discrepancies in a few cases:
Ideally, the protocol would give us some perfect ordering over events, so we don't have to do any kind of guessing / rejiggering ourselves, e.g. with something akin to MSC4033. Otherwise, we may be able to use the
all_events
internal ordering (or the ordering provided by the Event cache, in some future).The text was updated successfully, but these errors were encountered: