Matrix defines a set of open APIs for decentralised communication, suitable for securely publishing, persisting and subscribing to data over a global open federation of servers with no single point of control. Uses include Instant Messaging (IM), Voice over IP (VoIP) signalling, Internet of Things (IoT) communication, and bridging together existing communication silos - providing the basis of a new open real-time communication ecosystem. To propose a change to the Matrix Spec, see the explana...| Matrix Specification
The client-server API allows clients to send messages, control rooms and synchronise conversation history. It is designed to support both lightweight clients which store no state and lazy-load data from the server as required - as well as heavyweight clients which maintain a full local persistent copy of server state. API Standards These standards only apply to the APIs defined in the Matrix specification. APIs used by this specification but defined in other specifications, like the OAuth 2.0...| Matrix Specification
This room version builds on version 8 to add additional redaction rules that were unintentionally missed when incorporating v8. Client considerations See room version 8 for specific details regarding the addition of restricted rooms. Clients which implement the redaction algorithm locally should refer to the redactions section below for a full overview. Redactions [New in this version] m.room.member events now keep join_authorised_via_users_server in addition to other keys in content when bei...| Matrix Specification
Home of the Matrix specification for decentralised communication| Matrix Specification
The client-server API allows clients to send messages, control rooms and synchronise conversation history. It is designed to support both lightweight clients which store no state and lazy-load data from the server as required - as well as heavyweight clients which maintain a full local persistent copy of server state. API Standards The mandatory baseline for client-server communication in Matrix is exchanging JSON objects over HTTP APIs. More efficient transports may be specified in future as...| Matrix Specification
This room version builds on version 7 to introduce a new join rule that allows members to join the room based on membership in another room. This room version is known to have issues relating to redactions of member join events. Room version 9 should be preferred over v8 when creating rooms. Client considerations Clients are encouraged to expose the option for the join rule in their user interface for supported room versions.| Matrix Specification
This room version builds on version 6 to introduce knocking as a possible join rule and membership state. Client considerations This is the first room version to support knocking completely. As such, users will not be able to knock on rooms which are not based off v7. Though unchanged in this room version, clients which implement the redaction algorithm locally should refer to the redactions section below for a full overview.| Matrix Specification
This room version builds on version 5 while changing various authorization rules performed on events. Client considerations There are no client considerations introduced in this room version. Clients which implement the redaction algorithm locally should refer to the redactions section below for a full overview of the algorithm. Redactions [New in this version] All significant meaning for m.room.aliases has been removed from the redaction algorithm. The remaining rules are the same as past ro...| Matrix Specification
This room version builds on version 4 while enforcing signing key validity periods for events. Client considerations There are no client considerations introduced in this room version. Clients which implement the redaction algorithm locally should refer to the redactions section below for a full overview of the algorithm. Server implementation components The information contained in this section is strictly for server implementors. Applications which use the Client-Server API are generally un...| Matrix Specification
This room version builds on version 1 with an improved state resolution algorithm. Client considerations There are no client considerations introduced in this room version. Clients which implement the redaction algorithm locally should refer to the redactions section below for a full overview of the algorithm. Server implementation components The information contained in this section is strictly for server implementors. Applications which use the Client-Server API are generally unaffected by ...| Matrix Specification
This room version builds on version 9 to enforce that power level values be integers, and to introduce a new knock_restricted join rule, allowing prospective members to more easily join such a room. Client considerations This room version adds a new knock_restricted join rule to allow prospective members of a room join either through knocking (introduced in room version 7) or through “join restrictions” (introduced in room version 8 and refined in room version 9).| Matrix Specification
This room version is the first ever version for rooms, and contains the building blocks for other room versions. Client considerations Clients which implement the redaction algorithm locally should refer to the redactions section below. Redactions Upon receipt of a redaction event, the server must strip off any keys not in the following list: event_id type room_id sender state_key content hashes signatures depth prev_events prev_state auth_events origin origin_server_ts membership The content...| Matrix Specification
Matrix homeservers use the Federation APIs (also known as server-server APIs) to communicate with each other. Homeservers use these APIs to push messages to each other in real-time, to retrieve historic messages from each other, and to query profile and presence information about users on each other’s servers. The APIs are implemented using HTTPS requests between each of the servers. These HTTPS requests are strongly authenticated using public key signatures at the TLS transport layer and u...| Matrix Specification
This room version builds on version 3 using a different encoding for event IDs. Client considerations This room version changes the format form event IDs sent to clients. Clients should already be treating event IDs as opaque identifiers, and should not be concerned with the format of them. Clients should still encode the event ID when including it in a request path. Clients should expect to see event IDs changed from the format of $randomstring:example.org to something like $Rqnc-F-dvnEYJTyH...| Matrix Specification
Home of the Matrix specification for decentralised communication| Matrix Specification
Rooms are central to how Matrix operates, and have strict rules for what is allowed to be contained within them. Rooms can also have various algorithms that handle different tasks, such as what to do when two or more events collide in the underlying DAG. To allow rooms to be improved upon through new algorithms or rules, “room versions” are employed to manage a set of expectations for each room. New room versions are assigned as needed.| Matrix Specification
The Matrix client-server and server-server APIs are largely expressed in Matrix user identifiers. From time to time, it is useful to refer to users by other (“third-party”) identifiers, or “3PID"s, e.g. their email address or phone number. This Identity Service Specification describes how mappings between third-party identifiers and Matrix user identifiers can be established, validated, and used. This description technically may apply to any 3PID, but in practice has only been applied s...| Matrix Specification
The client-server API allows clients to send messages, control rooms and synchronise conversation history. It is designed to support both lightweight clients which store no state and lazy-load data from the server as required - as well as heavyweight clients which maintain a full local persistent copy of server state. API Standards The mandatory baseline for client-server communication in Matrix is exchanging JSON objects over HTTP APIs. More efficient transports may be specified in future as...| Matrix Specification
The Matrix client-server API and server-server APIs provide the means to implement a consistent self-contained federated messaging fabric. However, they provide limited means of implementing custom server-side behaviour in Matrix (e.g. gateways, filters, extensible hooks etc). The Application Service API (AS API) defines a standard API to allow such extensible functionality to be implemented irrespective of the underlying homeserver implementation. Application Services Application services ar...| Matrix Specification
Unpadded Base64 Unpadded Base64 refers to ‘standard’ Base64 encoding as defined in RFC 4648, without “=” padding. Specifically, where RFC 4648 requires that encoded data be padded to a multiple of four characters using = characters, unpadded Base64 omits this padding. For reference, RFC 4648 uses the following alphabet for Base 64: Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 ...| Matrix Specification
Matrix defines a set of open APIs for decentralised communication, suitable for securely publishing, persisting and subscribing to data over a global open federation of servers with no single point of control. Uses include Instant Messaging (IM), Voice over IP (VoIP) signalling, Internet of Things (IoT) communication, and bridging together existing communication silos - providing the basis of a new open real-time communication ecosystem. To propose a change to the Matrix Spec, see the explana...| Matrix Specification
The client-server API allows clients to send messages, control rooms and synchronise conversation history. It is designed to support both lightweight clients which store no state and lazy-load data from the server as required - as well as heavyweight clients which maintain a full local persistent copy of server state. API Standards The mandatory baseline for client-server communication in Matrix is exchanging JSON objects over HTTP APIs. More efficient transports may be specified in future as...| Matrix Specification
Home of the Matrix specification for decentralised communication| Matrix Specification
If you are interested in submitting a change to the Matrix Specification, please take note of the following guidelines. Most changes to the Specification require a formal proposal. Bug fixes, typos, and clarifications to existing behaviour do not need proposals - see the contributing guide for more information on what does and does not need a proposal. The proposal process involves some technical writing, having it reviewed by everyone, having the proposal being accepted, then actually having...| Matrix Specification
Matrix defines a set of open APIs for decentralised communication, suitable for securely publishing, persisting and subscribing to data over a global open federation of servers with no single point of control. Uses include Instant Messaging (IM), Voice over IP (VoIP) signalling, Internet of Things (IoT) communication, and bridging together existing communication silos - providing the basis of a new open real-time communication ecosystem. To propose a change to the Matrix Spec, see the explana...| Matrix Specification