Room DAG concepts

Edges

The word "edge" comes from graph theory lingo. An edge is just a connection between two events. In Synapse, we connect events by specifying their prev_events. A subsequent event points back at a previous event.

A (oldest) <---- B <---- C (most recent)

Depth and stream ordering

Events are normally sorted by (topological_ordering, stream_ordering) where topological_ordering is just depth. In other words, we first sort by depth and then tie-break based on stream_ordering. depth is incremented as new messages are added to the DAG. Normally, stream_ordering is an auto incrementing integer, but backfilled events start with stream_ordering=-1 and decrement.

/sync returns things in the order they arrive at the server (stream_ordering).
/messages (and /backfill in the federation API) return them in the order determined by the event graph (topological_ordering, stream_ordering).

The general idea is that, if you're following a room in real-time (i.e. /sync), you probably want to see the messages as they arrive at your server, rather than skipping any that arrived late; whereas if you're looking at a historical section of timeline (i.e. /messages), you want to see the best representation of the state of the room as others were seeing it at the time.

Forward extremity

Most-recent-in-time events in the DAG which are not referenced by any other events' prev_events yet.

The forward extremities of a room are used as the prev_events when the next event is sent.

Backwards extremity

The current marker of where we have backfilled up to and will generally be the oldest-in-time events we know of in the DAG.

This is an event where we haven't fetched all of the prev_events for.

Once we have fetched all of its prev_events, it's unmarked as a backwards extremity (although we may have formed new backwards extremities from the prev events during the backfilling process).

Outliers

We mark an event as an outlier when we haven't figured out the state for the room at that point in the DAG yet.

We won't necessarily have the prev_events of an outlier in the database, but it's entirely possible that we might. The status of whether we have all of the prev_events is marked as a backwards extremity.

For example, when we fetch the event auth chain or state for a given event, we mark all of those claimed auth events as outliers because we haven't done the state calculation ourself.

State groups

For every non-outlier event we need to know the state at that event. Instead of storing the full state for each event in the DB (i.e. a event_id -> state mapping), which is very space inefficient when state doesn't change, we instead assign each different set of state a "state group" and then have mappings of event_id -> state_group and state_group -> state.

Stage group edges

TODO: state_group_edges is a further optimization... notes from @Azrenbeth, https://pastebin.com/seUGVGeT

3.0 KiB Raw Blame History