Glossary

Definitions for the words, jargon, and acronyms used across Matrix and The Matrix.org Foundation. For the correct spelling and capitalisation of Matrix-related names, see the commonly used terms list instead.

Missing a term, or spotted a mistake? Suggest an edit on GitHub.

Core concepts

Application Service (AppService) #: A privileged piece of software, registered with a homeserver, that can puppet many virtual users and rooms at once. Bridges and some advanced bots are built as Application Services. Learn more →
Bridge #: A form of Application Service that relays messages between Matrix and a third-party chat platform (for example IRC, Slack, or Discord), so users on either side can talk to each other. Learn more →
Client #: An application people use to read and send messages on Matrix, such as Element. Clients talk to a homeserver, never directly to other clients. Learn more →
Event #: A single timestamped, signed item in a room's history: a message, a membership change, a room setting being updated, and so on. Rooms are built up from a directed acyclic graph of events. Learn more →
Federation #: The process by which independently-run homeservers exchange room data with each other, so users on different servers can share rooms without depending on a central server. Learn more →
Homeserver (HS) #: A server that hosts Matrix user accounts and participates in the network. Every account belongs to exactly one homeserver, identified by that server's domain. Learn more →
Identity server #: A separate, optional service that maps third-party identifiers (such as email addresses or phone numbers) to Matrix IDs, used when inviting someone by contact detail instead of by their Matrix ID.
Matrix user ID (Matrix ID, MXID, User ID) #: A user's identifier, made up of a local part and the domain of their homeserver, written as @username:example.com. Pronounced "at username on example dot com". Learn more →
Power level (PL) #: A per-user or per-action number in a room that determines what a user is allowed to do, such as sending certain event types, kicking, or banning. Learn more →
Room #: A conversation, shared between the homeservers of everyone taking part. Each participating server keeps its own local copy of the room, which is kept in sync with the others. Learn more →
Room ID #: The internal, permanent identifier of a room, written as !opaqueid:example.com. Unlike a room's published address, it never changes for the lifetime of the room. Learn more →
State event #: An event that represents a piece of persistent room state (such as the room name, topic, or a member's membership) rather than a one-off message. Only the latest state event for a given type and key is considered current. Learn more →

Governance

Governing Board (GB) #: The organ of The Matrix.org Foundation through which the ecosystem participates in its governance, made up of representatives elected or appointed from across the community. Learn more →
Matrix Spec Change (MSC) #: A proposal to change or extend the Matrix specification, following the process defined by the Spec Core Team. Learn more →
Spec Core Team (SCT) #: The team responsible for stewarding the Matrix specification itself, including reviewing and merging Matrix Spec Changes (MSCs). Learn more →
Working Group (WG) #: A standing group, formed under the Foundation's Governing Board, focused on getting a specific area of work done - for example events, or a part of the ecosystem. Learn more →

Security

Cross-signing #: A mechanism where a user signs their own devices with a private master key, so other users only need to verify that one master key to trust all of that user's current and future devices.
Device verification #: The process of two devices confirming each other's cryptographic identity keys out-of-band, so they can trust that messages are really coming from who they claim to be from. Learn more →
End-to-end encryption (E2EE) #: Encryption where messages are only readable by the sending and receiving devices, not by the homeservers relaying them. Matrix implements this using the Olm and Megolm cryptographic ratchets. Learn more →
Key backup #: An encrypted, server-side backup of a user's message decryption keys, so they aren't lost if all of a user's devices are lost or logged out at once.
Unable to decrypt (UTD) #: An error state shown for a message a client received but could not decrypt, usually because it never obtained the room key for that message.
vodozemac #: The Rust library implementing the Olm and Megolm cryptographic ratchets used for Matrix end-to-end encryption, replacing the older, now-deprecated libolm. Named after vodozémac, the Croatian word for "amphibian". Pronounced "vo-do-ze-mats". Learn more →

Trust & Safety

Account deactivation #: A destructive, irreversible action where an account is removed from all rooms and permanently deleted.
Account locking #: A reversible action where a user is prevented from logging in to their account, but the account itself is preserved in place.
Account suspension #: A reversible action similar to locking, except the user can still log in and read their account; they just cannot write (send messages, join rooms, and so on).