construct/include/ircd/m/room

Matrix Room Interface

The headers in this directory as well as ../room.h comprise the API for Matrix rooms. These interfaces may conduct IO for both the local database and the network; many calls may block an ircd::ctx for these purposes.

A room is composed from a timeline of events. We use several key-value tables as the database for room in addition to the raw event data itself.

• room_events This is the timeline for room events. We sort the keys of this table by an event's depth. This table allows us to scan the room's events as a collection. See: m::room::events.

• room_state This is the present state table for a room. We sort the keys of this table by (type,state_key). See: m::room::state.

• room_joined This is the present joined members list. It is technically redundant to that aspect of the room_state table but it is more efficient for us to maintain a separate table. See: m::room::origins which uses this table. Other interfaces are internally optimized by this table for some calls.

• room_head This is the collection of forward extremities (unreferenced) for a room. This is a fast-moving table that would otherwise be just a list in RAM; however persisting this through the database prevents recalculating it on startup.

• state_node This is a key-value store of nodes in a b-tree which is how we efficiently represent the state of a room at any past event. See: m::state subsystem. Note that m::state should not be confused with m::room::state. The latter is the user interface to room state which you are probably looking for; the former is the actual implementation of the b-tree and low-level details.

Sending & Transmission

The write interface for rooms is aggregated almost entirely in the index header ../room.h. These calls all converge on a single function commit which sends a partial event to a room via m::vm evaluation.

These calls all take a room structure as an argument which will be further explained in the Reading section. For now know that the room argument is lightweight and trivially constructed from a room_id. It can take a pointer to m::vm::eval options which offer extensive control over the transmission process.

All of the transmitting calls will block an ircd::ctx but the extent to which they do is configurable via the eval options. All of the calls return an event::id::buf of the event which they just committed to the room.

Above the lowest-level commit() function there are two mid-level send() suites. One suite creates and sends a state event to the room, the other creates and sends a non-state event. The overloads are distinguished by an extra state_key argument for the former.

Above the mid-level send() suites there is an accumulation of higher-level convenience functions, like message() and join() et al.

Reading & Access

The rest of these interfaces are read-only interfaces which present aspects of the room as efficiently as possible.

m::room

The principal structure is m::room in room/room.h. There are no ways to change an actual room through this interface, but an instance can be used with calls that do. Instances of room are lightweight, maintaining a reference to a room_id and an optional event_id. The data behind those references must stay in scope for the duration of the room instance.

When a room instance is used either for reading or writing, the event_id indicates a cursory position in the room to conduct operations. The room will be represented at that event_id. If no event_id is specified, the room will be represented at the latest "present" state; note the present state of a room is subject to change between calls.

The room class interface offers a convenience frontend which brings together the basic elements of the room::messages and room::state interfaces. These have different characteristics.

Other interfaces

The remainder of room/ is comprised of specialized interfaces which operate efficiently and friendly for their specific purpose.