Skip to main content

Room essentials

In Matrix, the place where you talk and see other users is called a Matrix room. This is Matrix's equivalent to channels that you might be familiar with on other platforms.

Events

Everything that happens in Matrix is expressed with events. This includes everything from the messages that you send to other users, notifications that are sent to show that you are typing, and profile changes such as changing your displayname within a Matrix room.

These events accumulate in the room timeline, which is the what you can see when you look at a Matrix room within your client.

You can read what the Matrix specification has to say for events here

State events

Matrix also has a concept of state events. These are special events that servers, bots, bridges and clients all use to store and retrieve data associated with the room easily. For example, the avatar and displayname of a given user in a Matrix room is stored within a state event to make it convenient for clients to access.

Authorization events

Matrix also has a concept of authorization events. These are special state events that are used to control what other events can be sent to the room. For example, the m.room.power_levels event is an authorization event that can be used to control which users can send messages to a room.

Your own membership event, of the type m.room.member, is also an authorization event, that authorizes you to participate within a Matrix room.

Membership

When you join a Matrix room, your homeserver creates a membership state event in the room that you are joining. This membership event tells all of the servers present within the room that you are also present so that they can authorise your messages. They will also use the event to remember to send your homeserver new messages.

This membership state event is called m.room.member, you can read the specification for the event here

The membership event has a protected content field called membership, which describes the membership state for a Matrix user in a room.

Whenever you ban or remove a user from a room, your homeserver has to create a membership event for that user that supersedes their current membership event. Explicitly marking the target user's membership as ban or leave.

Lazy bans

Unfortunately, due to the nature of Matrix and state events, Draupnir has to issue bans lazily. What this means is that Draupnir will not ban users from Matrix rooms until they have joined. Normally the ban will be issued by Draupnir instantaneously.

It is technically possible for room moderators to issue bans preemptively, however if there is another user within the room from the same server as the target of the ban, then the target will be force-joined to the Matrix room. This normally is not a problem, but for private rooms this behaviour can actually alert the target of the presence of the room and give them access to the title and profile picture.

The other reason Draupnir does not prematurely apply bans is that this would lead Draupnir to send thousands of redundant state events to every room that is being protected. This is because most of the users that are banned will never actually attempt to join a room. These events can degrade the performance of all servers that are participating.