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
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
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