Compare commits

...

14 commits

Author SHA1 Message Date
Johannes Marbach beddf10aa0
Merge 110ae95ce8 into fca171427f 2025-04-22 17:33:13 +01:00
Kévin Commaille fca171427f
Clarifications around third-party invites (#2083)
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
2025-04-22 15:48:50 +01:00
Kévin Commaille 81273df88e
Adjust margins in rendered endpoints (#2081)
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
* Use consistent spacing between tables and code blocks

Tables used `4 rem` which is more than the margin above a h2 title, which seems excessive. We change it to `2 rem` which matches the margin of code blocks and info boxes.

We also remove the margin on the last item of a `.rendered-data` block because this is just wasted space.

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

* Adjust spacing around h2 and h3 titles in `.rendered-data`

Given that h2 titles are always preceded by an horizontal rule, we don't need a lot of space to separate them from the previous section.

We also reduce the spacing when a h2 title is followed directly by a h3 title.

Finally, we add a little spacing below both so that tables are less close to the title.

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

* Add changelog

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

---------

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
2025-04-15 18:35:27 +01:00
Will Hunt 65b1db721d
Describe behaviour when the topic key is falsey in a m.room.topic event. (#2068)
We seem to have [updated this for m.room.name](https://github.com/matrix-org/matrix-spec/pull/1639) some years back but omitted it for topic.
2025-04-15 18:24:22 +01:00
Kévin Commaille c39c7d0680
Fix /sync example (#2077)
Some checks are pending
Spec / 🔎 Validate OpenAPI specifications (push) Waiting to run
Spec / 🔎 Check Event schema examples (push) Waiting to run
Spec / 🔎 Check OpenAPI definitions examples (push) Waiting to run
Spec / 🔎 Check JSON Schemas inline examples (push) Waiting to run
Spec / ⚙️ Calculate baseURL for later jobs (push) Waiting to run
Spec / 🐍 Build OpenAPI definitions (push) Blocked by required conditions
Spec / 📢 Run towncrier for changelog (push) Waiting to run
Spec / 📖 Build the spec (push) Blocked by required conditions
Spec / 🔎 Validate generated HTML (push) Blocked by required conditions
Spec / 📖 Build the historical backup spec (push) Blocked by required conditions
Spell Check / Spell Check with Typos (push) Waiting to run
* Fix sync example

The same event should not appear in `state` and in the `timeline` so we cannot use the same event twice.

To provide a `state` example we assume that with lazy-loading the user did not get the state event for `@example:example.org`, so we add one since they sent a message in the timeline.

The events that are referenced include a `room_id`, which doesn't appear on this endpoint, so we copy them without it.

Finally, the `join` event of `@alice:example.org` is wrong because the sender does not match the state key, which wouldn't pass the authorization rules.

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

* Fix the `m.room.member.yaml` example

This is a `join` event, and the `sender` doesn't match the `state_key`, so the event couldn't pass the authorization rules.

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

* Add changelog

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

---------

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
2025-04-15 14:47:21 +01:00
Travis Ralston 23ff7f1343
Fix minor typo in content hash calculations (#2128)
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
* Fix minor typo in content hash calculations

* Changelog
2025-04-07 14:28:00 -06:00
Andy Balaam 8a2c58b1b1
Typo "not" -> "no" (#2121)
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
* Typo "not" -> "no"

Signed-off-by: Andy Balaam <andy.balaam@matrix.org>

---------

Signed-off-by: Andy Balaam <andy.balaam@matrix.org>
2025-03-28 14:13:17 +00:00
Kim Brose 817ec5380f
Create funding-manifest-urls (#2115)
* Create funding-manifest-urls

* update funding-manifest-urls location, add news

Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>

---------

Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>
2025-03-28 13:19:23 +00:00
Travis Ralston 029be205b9 -> unstable
Some checks are pending
Spec / 🔎 Validate OpenAPI specifications (push) Waiting to run
Spec / 🔎 Check Event schema examples (push) Waiting to run
Spec / 🔎 Check OpenAPI definitions examples (push) Waiting to run
Spec / 🔎 Check JSON Schemas inline examples (push) Waiting to run
Spec / ⚙️ Calculate baseURL for later jobs (push) Waiting to run
Spec / 🐍 Build OpenAPI definitions (push) Blocked by required conditions
Spec / 📢 Run towncrier for changelog (push) Waiting to run
Spec / 📖 Build the spec (push) Blocked by required conditions
Spec / 🔎 Validate generated HTML (push) Blocked by required conditions
Spec / 📖 Build the historical backup spec (push) Blocked by required conditions
Spell Check / Spell Check with Typos (push) Waiting to run
2025-03-27 10:30:02 -06:00
Travis Ralston fe880fdaf4 v1.14 2025-03-27 10:28:55 -06:00
Travis Ralston 71ce620fc0
Add a v6 event format with correct depth limits (#2114)
* Add a v6 event format with correct `depth` limits

* Changelog

* numbers are hard
2025-03-27 10:23:09 -06:00
Travis Ralston cb6d039c57 Normalize changelog
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
2025-03-25 15:40:04 -06:00
Johannes Marbach c7581356bf
MSC4260: Reporting users (Client-Server API) (#2093)
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
* MSC4260: Reporting users (Client-Server API)

Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>

* Add changelog

* Update data/api/client-server/report_content.yaml

Co-authored-by: Kévin Commaille <76261501+zecakeh@users.noreply.github.com>

* Move option to consistently respond with 200 to user reporting endpoint

* Move optional random delay to event and user reporting endpoints

* Make reason required for user and room reports

* Fix requiredness syntax

---------

Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
Co-authored-by: Kévin Commaille <76261501+zecakeh@users.noreply.github.com>
2025-03-21 13:33:26 -06:00
Kévin Commaille 7fd49a2808
Set room version 11 as the default (#2105)
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
* Set room version 11 as the default

As per MSC4239

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

* Add changelog

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

---------

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
2025-03-20 12:00:33 -06:00
70 changed files with 590 additions and 253 deletions

View file

@ -316,13 +316,19 @@ Custom SCSS for the Matrix spec
h2 {
font-weight: $font-weight-bold;
font-size: 1.3rem;
margin: 3rem 0 .5rem 0;
margin: 1.5rem 0 1rem 0;
}
h3 {
font-weight: $font-weight-bold;
font-size: 1.1rem;
margin: 1.5rem 0 .75rem 0;
margin: 1.5rem 0 1rem 0;
}
/* Reduce top margin of h3 if previous sibling is a h2 */
h2 + h3 {
margin-top: 1rem;
}
hr {
@ -367,11 +373,6 @@ Custom SCSS for the Matrix spec
}
}
// add some space between two tables when they are right next to each other
& + table {
margin-top: 4rem;
}
caption {
caption-side: top;
color: $dark;
@ -443,6 +444,17 @@ Custom SCSS for the Matrix spec
}
}
/* Have consistent spacing around tables and examples */
table, .highlight {
margin-top: 0;
margin-bottom: 2rem;
/* We don't need the margin on the last child of the .rendered-data block */
&:last-child {
margin-bottom: 0;
}
}
pre {
border: 0;
border-left: solid 5px $secondary;

View file

@ -1 +0,0 @@
Clarify that arbitrary unicode is allowed in user/room IDs and room aliases.

View file

@ -1 +0,0 @@
The `POST /_matrix/client/v3/rooms/{roomId}/initialSync` endpoint is no longer deprecated, as it is still used for peeking.

View file

@ -1 +0,0 @@
Clarify wording in the `/join` endpoints' summaries and descriptions. Contributed by @HarHarLinks.

View file

@ -1 +0,0 @@
Clarify formats of string types.

View file

@ -1,2 +0,0 @@
Document the `instance_id` field of `Protocol Instance` in the responses to
`GET /_matrix/client/v3/thirdparty/protocols` and `GET /_matrix/client/v3/thirdparty/protocol/{protocol}`.

View file

@ -1 +0,0 @@
Applying redactions is a SHOULD for clients.

View file

@ -1 +0,0 @@
Remove `server_name` parameter from `/_matrix/client/v3/join/{roomIdOrAlias}` and `/_matrix/client/v3/knock/{roomIdOrAlias}` as per [MSC4213](https://github.com/matrix-org/matrix-spec-proposals/pull/4213).

View file

@ -1 +0,0 @@
Clarify which rooms are returned from `/hierarchy`.

View file

@ -0,0 +1 @@
Clarify behaviour when the `topic` key of a `m.room.topic` event is absent, null, or empty.

View file

@ -1 +0,0 @@
Clients can choose which history visibility options they offer to users when creating rooms.

View file

@ -0,0 +1 @@
Fix the example of the `GET /sync` endpoint and the `m.room.member` example used in several places.

View file

@ -1 +0,0 @@
Fix various typos throughout the specification.

View file

@ -0,0 +1,2 @@
Clarify the format of third-party invites, including the fact that identity
server public keys can be encoded using standard or URL-safe base64.

View file

@ -1 +0,0 @@
Fix various typos throughout the specification.

View file

@ -0,0 +1 @@
Clarify that public keys can be encoded using standard or URL-safe base64.

View file

@ -1 +0,0 @@
Generate the changelog release info with Hugo, rather than the changelog generation script.

View file

@ -1 +0,0 @@
Update release steps documentation.

View file

@ -1 +0,0 @@
Remove unused `release_date` from Hugo config.

View file

@ -1 +0,0 @@
Clarify that v1.0 of Matrix was a release prior to the current global versioning system.

View file

@ -1 +0,0 @@
Fix syntax highlighting and click-to-copy buttons for code blocks by purging less CSS.

View file

@ -1 +0,0 @@
Fix the version of the Identity Service API when Matrix 1.0 was introduced.

View file

@ -1 +0,0 @@
Fix parsing of nested slices in `resolve-refs` and `resolve-allof` partials.

View file

@ -1 +0,0 @@
Deduplicate the definition of `RoomKeysUpdateResponse`.

View file

@ -1 +0,0 @@
Deduplicate the definitions of `Invite3pid`.

View file

@ -1 +0,0 @@
Support more locations for examples in OpenAPI definitions and JSON schemas.

View file

@ -1 +0,0 @@
Add link to the git commit for the unstable changelog.

View file

@ -0,0 +1 @@
Adjust margins in rendered endpoints.

View file

@ -0,0 +1 @@
Add [well-known funding manifest urls](https://floss.fund/funding-manifest/) to spec to authorise https://matrix.org/funding.json. Contributed by @HarHarLinks.

View file

@ -1 +0,0 @@
For room versions 6 and 7, clarify in the authorization rules that `m.federate` must be checked and that events with rejected auth events must be rejected, for parity with all the other room versions.

View file

@ -1 +0,0 @@
Fix various typos throughout the specification.

View file

@ -1 +0,0 @@
Refactor PDU definitions to reduce duplication.

View file

@ -1 +0,0 @@
Remove the `origin` field in `PUT /send_join` responses, because it was never sent in the first place.

View file

@ -1 +0,0 @@
Clarify that `m.join_rules` should be in the `auth_events` of an `m.room.member` event with a `membership` of `knock`.

View file

@ -1 +0,0 @@
Remove an erroneous `room_id` field in a few examples.

View file

@ -0,0 +1,2 @@
Clarify the format of third-party invites, including the fact that identity
server public keys can be encoded using standard or URL-safe base64.

View file

@ -67,7 +67,7 @@ current_version_url = "https://spec.matrix.org/latest"
# The following is used when status = "stable", and is displayed in various UI elements on a released version
# of the spec.
# major = "1"
# minor = "13"
# minor = "14"
# User interface configuration
[params.ui]

View file

@ -0,0 +1,93 @@
---
title: v1.14 Changelog
linkTitle: v1.14
type: docs
layout: changelog
outputs:
- html
- checklist
date: 2025-03-27
---
## Client-Server API
**New Endpoints**
- Add `POST /_matrix/client/v3/users/{userId}/report`, as per [MSC4260](https://github.com/matrix-org/matrix-spec-proposals/pull/4260). ([#2093](https://github.com/matrix-org/matrix-spec/issues/2093))
**Removed Endpoints**
- Remove `server_name` parameter from `/_matrix/client/v3/join/{roomIdOrAlias}` and `/_matrix/client/v3/knock/{roomIdOrAlias}`, as per [MSC4213](https://github.com/matrix-org/matrix-spec-proposals/pull/4213). ([#2059](https://github.com/matrix-org/matrix-spec/issues/2059))
**Spec Clarifications**
- The `POST /_matrix/client/v3/rooms/{roomId}/initialSync` endpoint is no longer deprecated, as it is still used for peeking. ([#2036](https://github.com/matrix-org/matrix-spec/issues/2036))
- Clarify wording in the `/join` endpoints' summaries and descriptions. Contributed by @HarHarLinks. ([#2038](https://github.com/matrix-org/matrix-spec/issues/2038))
- Clarify formats of string types. ([#2046](https://github.com/matrix-org/matrix-spec/issues/2046))
- Fix various typos throughout the specification. ([#2047](https://github.com/matrix-org/matrix-spec/issues/2047), [#2048](https://github.com/matrix-org/matrix-spec/issues/2048), [#2080](https://github.com/matrix-org/matrix-spec/issues/2080), [#2091](https://github.com/matrix-org/matrix-spec/issues/2091))
- Document the `instance_id` field of `Protocol Instance` in the responses to `GET /_matrix/client/v3/thirdparty/protocols` and `GET /_matrix/client/v3/thirdparty/protocol/{protocol}`. ([#2051](https://github.com/matrix-org/matrix-spec/issues/2051))
- Applying redactions is a SHOULD for clients. ([#2055](https://github.com/matrix-org/matrix-spec/issues/2055))
- Clarify which rooms are returned from `/hierarchy`. ([#2064](https://github.com/matrix-org/matrix-spec/issues/2064))
- Clients can choose which history visibility options they offer to users when creating rooms. ([#2072](https://github.com/matrix-org/matrix-spec/issues/2072))
## Server-Server API
**Spec Clarifications**
- Remove the `origin` field in `PUT /send_join` responses, because it was never sent in the first place. ([#2050](https://github.com/matrix-org/matrix-spec/issues/2050))
- Clarify that `m.join_rules` should be in the `auth_events` of an `m.room.member` event with a `membership` of `knock`. ([#2063](https://github.com/matrix-org/matrix-spec/issues/2063))
- Remove an erroneous `room_id` field in a few examples. ([#2076](https://github.com/matrix-org/matrix-spec/issues/2076))
## Application Service API
No significant changes.
## Identity Service API
No significant changes.
## Push Gateway API
No significant changes.
## Room Versions
**Backwards Compatible Changes**
- Update the default room version to 11, as per [MSC4239](https://github.com/matrix-org/matrix-spec-proposals/pull/4239). ([#2105](https://github.com/matrix-org/matrix-spec/issues/2105))
**Spec Clarifications**
- For room versions 6 and 7, clarify in the authorization rules that `m.federate` must be checked and that events with rejected auth events must be rejected, for parity with all the other room versions. ([#2065](https://github.com/matrix-org/matrix-spec/issues/2065))
- Fix various typos throughout the specification. ([#2066](https://github.com/matrix-org/matrix-spec/issues/2066))
- Refactor PDU definitions to reduce duplication. ([#2070](https://github.com/matrix-org/matrix-spec/issues/2070))
- Clarify the maximum `depth` value for room versions 6, 7, 8, 9, 10, and 11. ([#2114](https://github.com/matrix-org/matrix-spec/issues/2114))
## Appendices
**Spec Clarifications**
- Clarify that arbitrary unicode is allowed in user/room IDs and room aliases. ([#1506](https://github.com/matrix-org/matrix-spec/issues/1506))
## Internal Changes/Tooling
**Spec Clarifications**
- Generate the changelog release info with Hugo, rather than the changelog generation script. ([#2033](https://github.com/matrix-org/matrix-spec/issues/2033))
- Update release steps documentation. ([#2041](https://github.com/matrix-org/matrix-spec/issues/2041))
- Remove unused `release_date` from Hugo config. ([#2042](https://github.com/matrix-org/matrix-spec/issues/2042))
- Clarify that v1.0 of Matrix was a release prior to the current global versioning system. ([#2045](https://github.com/matrix-org/matrix-spec/issues/2045))
- Fix syntax highlighting and click-to-copy buttons for code blocks by purging less CSS. ([#2049](https://github.com/matrix-org/matrix-spec/issues/2049))
- Fix the version of the Identity Service API when Matrix 1.0 was introduced. ([#2061](https://github.com/matrix-org/matrix-spec/issues/2061))
- Fix parsing of nested slices in `resolve-refs` and `resolve-allof` partials. ([#2069](https://github.com/matrix-org/matrix-spec/issues/2069))
- Deduplicate the definition of `RoomKeysUpdateResponse`. ([#2073](https://github.com/matrix-org/matrix-spec/issues/2073))
- Deduplicate the definitions of `Invite3pid`. ([#2074](https://github.com/matrix-org/matrix-spec/issues/2074))
- Support more locations for examples in OpenAPI definitions and JSON schemas. ([#2076](https://github.com/matrix-org/matrix-spec/issues/2076))
- Add link to the git commit for the unstable changelog. ([#2078](https://github.com/matrix-org/matrix-spec/issues/2078))

View file

@ -29,3 +29,9 @@ is in before accepting a report.
based on whether or not the reporting user is joined to the room. This is
because users can be exposed to harmful content without being joined to a
room. For instance, through room directories or invites.
{{% added-in v="1.14" %}} Similarly, servers MUST NOT restrict user reports
based on whether or not the reporting user is joined to any rooms that the
reported user is joined to. This is because users can be exposed to harmful
content without being joined to a room. For instance, through user
directories or invites.

View file

@ -58,7 +58,7 @@ available on all their clients. Unless the user specifies otherwise,
clients will try to use the default key to decrypt secrets.
Clients that want to present a simplified interface to users by not supporting
multiple keys should use the default key if one is specified. If not default
multiple keys should use the default key if one is specified. If no default
key is specified, the client may behave as if there is no key is present at
all. When such a client creates a key, it should mark that key as being the
default key.

View file

@ -5,8 +5,8 @@ This module adds in support for inviting new members to a room where
their Matrix user ID is not known, instead addressing them by a third-party
identifier such as an email address. There are two flows here; one
if a Matrix user ID is known for the third-party identifier, and one if
not. Either way, the client calls [`/invite`](#post_matrixclientv3roomsroomidinvite) with the details of the
third-party identifier.
not. Either way, the client calls [`/invite`](#thirdparty_post_matrixclientv3roomsroomidinvite)
with the details of the third-party identifier.
The homeserver asks the identity server whether a Matrix user ID is
known for that identifier:
@ -37,10 +37,12 @@ A client asks a server to invite a user by their third-party identifier.
#### Server behaviour
Upon receipt of an [`/invite`](#post_matrixclientv3roomsroomidinvite), the server is expected to look up the
third-party identifier with the provided identity server. If the lookup
yields a result for a Matrix User ID then the normal invite process can
be initiated. This process ends up looking like this:
Upon receipt of an [`/invite`](#thirdparty_post_matrixclientv3roomsroomidinvite),
the server is expected to look up the third-party identifier with the provided
identity server by making a call to [`/_matrix/identity/v2/lookup`](/identity-service-api/#post_matrixidentityv2lookup).
If the lookup yields a result for a Matrix User ID then the normal [invite
process](/server-server-api/#inviting-to-a-room) can be initiated. This process
ends up looking like this:
```
+---------+ +-------------+ +-----------------+
@ -66,10 +68,11 @@ be initiated. This process ends up looking like this:
| | |
```
However, if the lookup does not yield a bound User ID, the homeserver
must store the invite on the identity server and emit a valid
`m.room.third_party_invite` event to the room. This process ends up
looking like this:
However, if the lookup does not yield a bound User ID, the homeserver must store
the invite on the identity server with a call to
[`/_matrix/identity/v2/store-invite`](/identity-service-api/#post_matrixidentityv2store-invite)
and emit a valid [`m.room.third_party_invite`](#mroomthird_party_invite) event
to the room. This process ends up looking like this:
```
+---------+ +-------------+ +-----------------+
@ -101,15 +104,18 @@ looking like this:
| | |
```
All homeservers MUST verify the signature in the event's
`content.third_party_invite.signed` object.
The third-party user will then need to verify their identity, which results in a
request to [`/_matrix/federation/v1/3pid/onbind`](/server-server-api/#put_matrixfederationv13pidonbind)
from the identity server to the homeserver that bound the third-party identifier
to a user. The homeserver then exchanges the `m.room.third_party_invite` event
in the room for a complete [`m.room.member`](#mroommember) event with
`content.membership: invite` and a `content.third_party_invite` property for the
user that has bound the third-party identifier. If the invitee is on a different
homeserver than the inviting user, the invitee's homeserver makes a request to
[`/_matrix/federation/v1/exchange_third_party_invite/{roomId}`](/server-server-api/#put_matrixfederationv1exchange_third_party_inviteroomid).
The third-party user will then need to verify their identity, which
results in a call from the identity server to the homeserver that bound
the third-party identifier to a user. The homeserver then exchanges the
`m.room.third_party_invite` event in the room for a complete
`m.room.member` event for `membership: invite` for the user that has
bound the third-party identifier.
All homeservers MUST verify the signature in the `m.room.member` event's
`content.third_party_invite.signed` object.
If a homeserver is joining a room for the first time because of an
`m.room.third_party_invite`, the server which is already participating
@ -193,8 +199,8 @@ at any time - the completion is not shown in the diagram.
H1 MUST verify the request from H3 to ensure the `signed` property is
correct as well as the `key_validity_url` as still being valid. This is
done by making a request to the [identity server
/isvalid](/identity-service-api/#get_matrixidentityv2pubkeyisvalid)
done by making a request to the identity server's
[`/pubkey/isvalid`](/identity-service-api/#get_matrixidentityv2pubkeyisvalid)
endpoint, using the provided URL rather than constructing a new one. The
query string and response for the provided URL must match the Identity
Service Specification.

View file

@ -52,7 +52,7 @@ stable and unstable periodically for a variety of reasons, including
discovered security vulnerabilities and age.
Clients should not ask room administrators to upgrade their rooms if the
room is running a stable version. Servers SHOULD use **room version 10** as
room is running a stable version. Servers SHOULD use **room version 11** as
the default room version when creating new rooms.
The available room versions are:

View file

@ -0,0 +1,4 @@
Events in rooms of this version have the following structure:
{{% definition path="api/server-server/definitions/pdu_v6" %}}

View file

@ -281,7 +281,7 @@ completeness.
### Event format
{{% rver-fragment name="v4-event-format" %}}
{{% rver-fragment name="v6-event-format" %}}
### State resolution

View file

@ -39,6 +39,13 @@ in [room version 5](/rooms/v5).
[See above](#redactions).
### Event format
{{% added-in v=6 %}} Through enforcement of [Canonical JSON](#canonical-json),
the `depth` limit has been reduced in this room version.
{{% rver-fragment name="v6-event-format" %}}
### Authorization rules
{{% added-in v=6 %}} Rule 4, which related specifically to events
@ -229,10 +236,6 @@ completeness.
{{% rver-fragment name="v4-event-ids" %}}
### Event format
{{% rver-fragment name="v4-event-format" %}}
#### Deprecated event content schemas
{{% rver-fragment name="v1-deprecated-formatting-off-spec" %}}

View file

@ -225,7 +225,7 @@ completeness.
### Event format
{{% rver-fragment name="v4-event-format" %}}
{{% rver-fragment name="v6-event-format" %}}
#### Deprecated event content schemas

View file

@ -109,7 +109,7 @@ completeness.
### Event format
{{% rver-fragment name="v4-event-format" %}}
{{% rver-fragment name="v6-event-format" %}}
#### Deprecated event content schemas

View file

@ -74,7 +74,7 @@ completeness.
### Event format
{{% rver-fragment name="v4-event-format" %}}
{{% rver-fragment name="v6-event-format" %}}
#### Deprecated event content schemas

View file

@ -970,9 +970,8 @@ the event to other servers in the room.
## Third-party invites
{{% boxes/note %}}
More information about third-party invites is available in the
[Client-Server API](/client-server-api) under
the Third-party Invites module.
More information about third-party invites is available in the Client-Server API
under the [Third-party invites](/client-server-api/#third-party-invites) module.
{{% /boxes/note %}}
When a user wants to invite another user in a room but doesn't know the
@ -985,38 +984,41 @@ API](/identity-service-api).
### Cases where an association exists for a third-party identifier
If the third-party identifier is already bound to a Matrix ID, a lookup
request on the identity server will return it. The invite is then
processed by the inviting homeserver as a standard `m.room.member`
invite event. This is the simplest case.
If the third-party identifier is already bound to a Matrix ID, a [lookup
request](/identity-service-api/#post_matrixidentityv2lookup) on the identity
server will return it. The invite is then processed by the inviting homeserver
as a [standard `m.room.member` invite event](#inviting-to-a-room). This is the
simplest case.
### Cases where an association doesn't exist for a third-party identifier
If the third-party identifier isn't bound to any Matrix ID, the inviting
homeserver will request the identity server to store an invite for this
identifier and to deliver it to whoever binds it to its Matrix ID. It
will also send an `m.room.third_party_invite` event in the room to
specify a display name, a token and public keys the identity server
provided as a response to the invite storage request.
homeserver will request the identity server to [store an invite](/identity-service-api/#invitation-storage)
for this identifier and to deliver it to whoever binds it to its Matrix ID. It
will also send an [`m.room.third_party_invite`](/client-server-api/#mroomthird_party_invite)
event in the room to specify a display name, a token and public keys the
identity server provided as a response to the invite storage request.
When a third-party identifier with pending invites gets bound to a
Matrix ID, the identity server will send a POST request to the ID's
homeserver as described in the [Invitation
Storage](/identity-service-api#invitation-storage)
section of the Identity Service API.
When a third-party identifier with pending invites gets bound to a Matrix ID,
the identity server will send a request to the [`/3pid/onbind`](#put_matrixfederationv13pidonbind)
endpoint of the the ID's homeserver as described in the [Invitation
Storage](/identity-service-api#invitation-storage) section of the Identity
Service API.
The following process applies for each invite sent by the identity
server:
The invited homeserver will create an `m.room.member` invite event
containing a special `third_party_invite` section containing the token
and a signed object, both provided by the identity server.
The invited homeserver will create an [`m.room.member`](/client-server-api/#mroommember)
invite event containing a special `third_party_invite` section containing the
token and a `signed` object, both provided by the identity server.
If the invited homeserver is in the room the invite came from, it can
auth the event and send it.
However, if the invited homeserver isn't in the room the invite came
from, it will need to request the room's homeserver to auth the event.
from, it will need to request the inviting homeserver to auth the event
at the [`/exchange_third_party_invite`](#put_matrixfederationv1exchange_third_party_inviteroomid)
endpoint.
{{% http-api spec="server-server" api="third_party_invite" %}}
@ -1336,7 +1338,7 @@ calculated as follows.
The *content hash* of an event covers the complete event including the
*unredacted* contents. It is calculated as follows.
First, any existing `unsigned`, `signature`, and `hashes` members are
First, any existing `unsigned`, `signatures`, and `hashes` properties are
removed. The resulting object is then encoded as [Canonical
JSON](/appendices#canonical-json), and the JSON is hashed using
SHA-256.

View file

@ -45,7 +45,9 @@ paths:
properties:
reason:
type: string
description: The reason the room is being reported.
description: The reason the room is being reported. May be blank.
required:
- reason
required: true
security:
- accessTokenQuery: []
@ -88,12 +90,11 @@ paths:
Reports an event as inappropriate to the server, which may then notify
the appropriate people. The caller must be joined to the room to report
it.
It might be possible for clients to deduce whether an event exists by
timing the response, as only a report for an event that does exist
will require the homeserver to check whether a user is joined to
the room. To combat this, homeserver implementations should add
a random delay when generating a response.
Furthermore, it might be possible for clients to deduce whether a reported
event exists by timing the response. This is because only a report for an
existing event will require the homeserver to do further processing. To
combat this, homeservers MAY add a random delay when generating a response.
operationId: reportEvent
parameters:
- in: path
@ -164,6 +165,88 @@ paths:
}
tags:
- Reporting content
"/users/{userId}/report":
post:
x-addedInMatrixVersion: "1.14"
summary: Report a user as inappropriate.
description: |-
Reports a user as inappropriate to the server, which may then notify
the appropriate people. How such information is delivered is left up to
implementations. The caller is not required to be joined to any rooms
that the reported user is joined to.
Clients may wish to [ignore](#ignoring-users) users after reporting them.
Clients could infer whether a reported user exists based on the 404 response.
Homeservers that wish to conceal this information MAY return 200 responses
regardless of the existence of the reported user.
Furthermore, it might be possible for clients to deduce whether a reported
user exists by timing the response. This is because only a report for an
existing user will require the homeserver to do further processing. To
combat this, homeservers MAY add a random delay when generating a response.
operationId: reportUser
parameters:
- in: path
name: userId
description: The user being reported.
required: true
example: "@someguy:example.com"
schema:
type: string
format: mx-user-id
pattern: "^@"
requestBody:
content:
application/json:
schema:
type: object
example: {
"reason": "this makes me sad"
}
properties:
reason:
type: string
description: The reason the room is being reported. May be blank.
required:
- reason
required: true
security:
- accessTokenQuery: []
- accessTokenBearer: []
responses:
"200":
description: |
The user has been reported successfully or the server chose
to not disclose whether the users exists.
content:
application/json:
schema:
type: object
examples:
response:
value: {}
"404":
description: |-
The user was not found on the homeserver.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "The user was not found."
}
"429":
description: This request was rate-limited.
content:
application/json:
schema:
$ref: definitions/errors/rate_limited.yaml
tags:
- Reporting content
servers:
- url: "{protocol}://{hostname}{basePath}"
variables:

View file

@ -441,17 +441,57 @@ paths:
"state": {
"events": [
{
"$ref": "../../event-schemas/examples/m.room.member.yaml"
"content": {
"avatar_url": "mxc://example.org/SFHyPlCeYUSFFxlgbQYZmoEoe",
"displayname": "Example user",
"membership": "join"
},
"event_id": "$143273976499sgjks:example.org",
"origin_server_ts": 1432735824653,
"sender": "@example:example.org",
"state_key": "@example:example.org",
"type": "m.room.member",
"unsigned": {
"age": 45603,
"membership": "join"
}
}
]
},
"timeline": {
"events": [
{
"$ref": "../../event-schemas/examples/m.room.member.yaml"
"content": {
"avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF",
"displayname": "Alice Margatroid",
"membership": "join",
"reason": "Looking for support"
},
"event_id": "$143273582443PhrSn:example.org",
"origin_server_ts": 1432735824653,
"sender": "@alice:example.org",
"state_key": "@alice:example.org",
"type": "m.room.member",
"unsigned": {
"age": 1234,
"membership": "join"
}
},
{
"$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
"content": {
"body": "This is an example text message",
"format": "org.matrix.custom.html",
"formatted_body": "<b>This is an example text message</b>",
"msgtype": "m.text"
},
"event_id": "$143273582443PhrSn:example.org",
"origin_server_ts": 1432735824653,
"sender": "@example:example.org",
"type": "m.room.message",
"unsigned": {
"age": 1234,
"membership": "join"
}
}
],
"limited": true,

View file

@ -57,9 +57,6 @@ paths:
- A signature of the token, signed with the identity server's private key
- The matrix user ID who invited them to the room
If a token is requested from the identity server, the homeserver will
append a `m.room.third_party_invite` event to the room.
operationId: inviteBy3PID
security:
- accessTokenQuery: []
@ -72,6 +69,8 @@ paths:
example: "!d41d8cd:matrix.org"
schema:
type: string
format: mx-room-id
pattern: "^!"
requestBody:
content:
application/json:
@ -90,7 +89,9 @@ paths:
value: {}
"403":
description: |-
You do not have permission to invite the user to the room. A meaningful `errcode` and description error text will be returned. Example reasons for rejections are:
You do not have permission to invite the user to the room. A
meaningful `errcode` and description error text will be returned.
Example reasons for rejections are:
- The invitee has been banned from the room.
- The invitee is already a member of the room.

View file

@ -43,7 +43,8 @@ paths:
properties:
public_key:
type: string
description: Unpadded Base64 encoded public key.
description: |-
[Unpadded Base64](/appendices/#unpadded-base64)-encoded public key.
required:
- public_key
examples:
@ -74,7 +75,8 @@ paths:
- in: query
name: public_key
required: true
description: The unpadded base64-encoded public key to check.
description: |-
The [unpadded Base64](/appendices/#unpadded-base64)-encoded public key to check.
example: VXuGitF39UH5iRfvbIknlvlAVKgD1BsLDMvBf0pmp7c
schema:
type: string
@ -105,7 +107,14 @@ paths:
- in: query
name: public_key
required: true
description: The unpadded base64-encoded public key to check.
description: |-
The [unpadded Base64](/appendices/#unpadded-base64)-encoded public
key to check.
This MUST be the exact same encoded string returned in the response
of the [`/store-invite`](/identity-service-api/#post_matrixidentityv2store-invite)
endpoint, or found in the corresponding [`m.room.third_party_invite`](/client-server-api/#mroomthird_party_invite)
event, so it may use the standard or URL-safe alphabets.
example: VXuGitF39UH5iRfvbIknlvlAVKgD1BsLDMvBf0pmp7c
schema:
type: string

View file

@ -42,7 +42,7 @@ paths:
(if present) from the request here.
Also, the generated ephemeral public key will be listed as valid on
requests to `/_matrix/identity/v2/pubkey/ephemeral/isvalid`.
requests to [`/_matrix/identity/v2/pubkey/ephemeral/isvalid`](/identity-service-api/#get_matrixidentityv2pubkeyephemeralisvalid).
Currently, invites may only be issued for 3pids of the `email` medium.
@ -70,10 +70,14 @@ paths:
room_id:
type: string
description: The Matrix room ID to which the user is invited
format: mx-room-id
pattern: "^!"
example: "!something:example.org"
sender:
type: string
description: The Matrix user ID of the inviting user
format: mx-user-id
pattern: "^@"
example: "@bob:example.com"
room_alias:
type: string
@ -81,12 +85,16 @@ paths:
The Matrix room alias for the room to which the user is
invited. This should be retrieved from the `m.room.canonical_alias`
state event.
format: mx-room-alias
pattern: "^#"
example: "#somewhere:example.org"
room_avatar_url:
type: string
description: |-
The Content URI for the room to which the user is invited. This should
be retrieved from the `m.room.avatar` state event.
format: mx-mxc-uri
pattern: "^mxc:\\/\\/"
example: mxc://example.org/s0meM3dia
room_join_rules:
type: string
@ -108,6 +116,8 @@ paths:
type: string
description: The Content URI for the avatar of the user ID initiating the
invite.
format: mx-mxc-uri
pattern: "^mxc:\\/\\/"
example: mxc://example.org/an0th3rM3dia
room_type:
type: string
@ -146,7 +156,7 @@ paths:
public_key:
type: string
description: |
The public key, encoded using [unpadded Base64](/appendices/#unpadded-base64).
The public key, encoded using standard or URL-safe [unpadded Base64](/appendices/#unpadded-base64).
key_validity_url:
type: string
description: |

View file

@ -41,13 +41,6 @@ properties:
type: object
description: The content of the event.
example: {"key": "value"}
depth:
type: integer
description: |-
The maximum depth of the `prev_events`, plus one. Must be less than the
maximum value for an integer (2^63 - 1). If the room's depth is already at
the limit, the depth must be set to the limit.
example: 12
hashes:
$ref: "event_hash.yaml"
signatures:

View file

@ -28,6 +28,13 @@ allOf:
type: string
description: For redaction events, the ID of the event being redacted.
example: "$def456:matrix.org"
depth:
type: integer
description: |-
The maximum depth of the `prev_events`, plus one. Must be less than the
maximum value for an integer (2^63 - 1). If the room's depth is already at
the limit, the depth must be set to the limit.
example: 12
auth_events:
type: array
description: |-

View file

@ -17,6 +17,16 @@ description: A persistent data unit (event) for room version 11 and beyond.
example:
$ref: "../examples/pdu_v11.json"
allOf:
# v11 is the v4 event, but without redacts.
# v11 is the v6 event, but without redacts.
- $ref: "components/pdu_base.yaml"
- $ref: "components/auth_events_prev_events_v4.yaml"
- $ref: "components/auth_events_prev_events_v4.yaml"
- type: object
properties:
# v6 enforces Canonical JSON and therefore needs a depth limit change
depth:
type: integer
description: |-
The maximum depth of the `prev_events`, plus one. Must be less than the
maximum value for an integer (2^53 - 1). If the room's depth is already at
the limit, the depth must be set to the limit.
example: 12

View file

@ -24,6 +24,13 @@ allOf:
type: string
description: For redaction events, the ID of the event being redacted.
example: "$def/456+oldevent"
depth:
type: integer
description: |-
The maximum depth of the `prev_events`, plus one. Must be less than the
maximum value for an integer (2^63 - 1). If the room's depth is already at
the limit, the depth must be set to the limit.
example: 12
auth_events:
type: array
items:

View file

@ -26,3 +26,10 @@ allOf:
type: string
description: For redaction events, the ID of the event being redacted.
example: "$def_456-oldevent"
depth:
type: integer
description: |-
The maximum depth of the `prev_events`, plus one. Must be less than the
maximum value for an integer (2^63 - 1). If the room's depth is already at
the limit, the depth must be set to the limit.
example: 12

View file

@ -0,0 +1,36 @@
# Copyright 2025 The Matrix.org Foundation C.I.C.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
type: object
title: Persistent Data Unit
description: |-
A persistent data unit (event) for room versions 4, 5, 6, 7, 8, 9 and 10.
example:
$ref: "../examples/pdu_v4.json"
allOf:
- $ref: "components/pdu_base.yaml"
- $ref: "components/auth_events_prev_events_v4.yaml"
- type: object
properties:
redacts:
type: string
description: For redaction events, the ID of the event being redacted.
example: "$def_456-oldevent"
# v6 enforces Canonical JSON and therefore needs a depth limit change
depth:
type: integer
description: |-
The maximum depth of the `prev_events`, plus one. Must be less than the
maximum value for an integer (2^53 - 1). If the room's depth is already at
the limit, the depth must be set to the limit.
example: 12

View file

@ -35,6 +35,8 @@ paths:
example: "!abc123:matrix.org"
schema:
type: string
format: mx-room-id
pattern: "^!"
requestBody:
content:
application/json:
@ -50,16 +52,22 @@ paths:
description: |-
The room ID the event is for. Must match the ID given in
the path.
format: mx-room-id
pattern: "^!"
example: "!abc123:matrix.org"
sender:
type: string
description: |-
The user ID of the user who sent the original `m.room.third_party_invite`
event.
format: mx-user-id
pattern: "^@"
example: "@joe:matrix.org"
state_key:
type: string
description: The user ID of the invited user
format: mx-user-id
pattern: "^@"
example: "@someone:example.org"
content:
type: object
@ -82,45 +90,7 @@ paths:
third-party identifier.
example: alice
signed:
type: object
description: |-
A block of content which has been signed, which servers can use to
verify the event.
title: Invite Signatures
properties:
signatures:
type: object
title: Signatures
additionalProperties:
type: object
additionalProperties:
type: string
description: |-
The server signatures for this event.
The signature is calculated using the process
described at [Signing JSON](/appendices/#signing-json).
example:
magic.forest:
ed25519:3: fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg
mxid:
type: string
description: The invited matrix user ID
example: "@alice:localhost"
token:
type: string
description: The token used to verify the event
example: abc123
required:
- signatures
- mxid
- token
example:
mxid: "@alice:localhost"
token: abc123
signatures:
magic.forest:
ed25519:3: fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg
$ref: ../../event-schemas/schema/components/signed_third_party_invite.yaml
required:
- display_name
- signed
@ -215,6 +185,8 @@ paths:
mxid:
type: string
description: The user that is now bound to the third-party identifier.
format: mx-user-id
pattern: "^@"
example: "@alice:matrix.org"
invites:
type: array
@ -237,59 +209,23 @@ paths:
mxid:
type: string
description: The now-bound user ID that received the invite.
format: mx-user-id
pattern: "^@"
example: "@alice:matrix.org"
room_id:
type: string
description: The room ID the invite is valid for.
format: mx-room-id
pattern: "^!"
example: "!somewhere:example.org"
sender:
type: string
description: The user ID that sent the invite.
format: mx-user-id
pattern: "^@"
example: "@bob:matrix.org"
# TODO (TravisR): Make this reusable when doing IS spec changes
# also make sure it isn't lying about anything, like the key version
signed:
type: object
title: Identity Server Signatures
description: |-
Signature from the identity server using a long-term private
key.
properties:
mxid:
type: string
description: |-
The user ID that has been bound to the third-party
identifier.
example: "@alice:matrix.org"
token:
type: string
# TODO: What is this actually?
description: A token.
example: Hello World
signatures:
type: object
title: Identity Server Signature
description: |-
The signature from the identity server. The `string` key
is the identity server's domain name, such as vector.im
additionalProperties:
type: object
title: Identity Server Domain Signature
description: The signature for the identity server.
properties:
ed25519:0:
type: string
description: The signature.
example: SomeSignatureGoesHere
required:
- ed25519:0
example:
vector.im:
ed25519:0: SomeSignatureGoesHere
required:
- mxid
- token
- signatures
$ref: ../../event-schemas/schema/components/signed_third_party_invite.yaml
required:
- medium
- address

View file

@ -1,6 +1,7 @@
{
"$ref": "core/state_event.json",
"state_key": "@alice:example.org",
"sender": "@alice:example.org",
"type": "m.room.member",
"content": {
"membership": "join",

View file

@ -0,0 +1,45 @@
title: SignedThirdPartyInvite
description: |-
A block of content which has been signed by the identity server, which
homeservers can use to verify the event. Clients should ignore this.
type: object
properties:
mxid:
description: |-
The user ID that has been bound to the third-party identifier.
type: string
format: mx-user-id
pattern: "^@"
example: "@alice:example.org"
signatures:
title: IdentityServerSignatures
description: |-
The identity server signatures for this block. This is a map of identity
server name to signing key identifier to base64-encoded signature.
The signatures are calculated using the process described at
[Signing JSON](/appendices/#signing-json).
type: object
additionalProperties:
type: object
additionalProperties:
type: string
example: {
"magic.forest": {
"ed25519:3": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
}
}
token:
description: |-
The token generated by the identity server at the
[`/store_invite`](/identity-service-api/#post_matrixidentityv2store-invite)
endpoint.
It matches the `state_key` of the corresponding [`m.room.third_party_invite`](/client-server-api/#mroomthird_party_invite)
event.
type: string
example: "abc123"
required:
- mxid
- signatures
- token

View file

@ -2,17 +2,27 @@
allOf:
- $ref: core-event-schema/state_event.yaml
description: |-
Adjusts the membership state for a user in a room. It is preferable to use the membership APIs (`/rooms/<room id>/invite` etc) when performing membership actions rather than adjusting the state directly as there are a restricted set of valid transformations. For example, user A cannot force user B to join a room, and trying to force this state change directly will fail.
Adjusts the membership state for a user in a room. It is preferable to use the membership APIs
(`/rooms/<room id>/invite` etc) when performing membership actions rather than adjusting the
state directly as there are a restricted set of valid transformations. For example, user A cannot
force user B to join a room, and trying to force this state change directly will fail.
The following membership states are specified:
- `invite` - The user has been invited to join a room, but has not yet joined it. They may not participate in the room until they join.
- `join` - The user has joined the room (possibly after accepting an invite), and may participate in it.
- `leave` - The user was once joined to the room, but has since left (possibly by choice, or possibly by being kicked).
- `ban` - The user has been banned from the room, and is no longer allowed to join it until they are un-banned from the room (by having their membership state set to a value other than `ban`).
- `knock` - The user has knocked on the room, requesting permission to participate. They may not participate in the room until they join.
- `invite` - The user has been invited to join a room, but has not yet joined it. They may not
participate in the room until they join.
- `join` - The user has joined the room (possibly after accepting an invite), and may participate
in it.
- `leave` - The user was once joined to the room, but has since left (possibly by choice, or
possibly by being kicked).
- `ban` - The user has been banned from the room, and is no longer allowed to join it until they
are un-banned from the room (by having their membership state set to a value other than `ban`).
- `knock` - The user has knocked on the room, requesting permission to participate. They may not
participate in the room until they join.
The `third_party_invite` property will be set if this invite is an `invite` event and is the successor of an `m.room.third_party_invite` event, and absent otherwise.
The `third_party_invite` property will be set if this invite is an `invite` event and is the
successor of an [`m.room.third_party_invite`](/client-server-api/#mroomthird_party_invite) event,
and absent otherwise.
This event may also include an `invite_room_state` key inside the event's `unsigned` data.
If present, this contains an array of [stripped state events](/client-server-api/#stripped-state)
@ -57,63 +67,54 @@ properties:
- ban
type: string
is_direct:
description: Flag indicating if the room containing this event was created with the intention of being a direct chat. See [Direct Messaging](/client-server-api/#direct-messaging).
description: |-
Flag indicating if the room containing this event was created with the intention of being
a direct chat. See [Direct Messaging](/client-server-api/#direct-messaging).
type: boolean
join_authorised_via_users_server:
x-addedInMatrixVersion: "1.2"
type: string
description: |-
Usually found on `join` events, this field is used to denote which homeserver (through representation of a user with sufficient power level)
authorised the user's join. More information about this field can be found in the [Restricted Rooms Specification](/client-server-api/#restricted-rooms).
Usually found on `join` events, this field is used to denote which homeserver (through
representation of a user with sufficient power level) authorised the user's join. More
information about this field can be found in the [Restricted Rooms Specification](/client-server-api/#restricted-rooms).
Client and server implementations should be aware of the [signing implications](/rooms/v8/#authorization-rules) of including this
field in further events: in particular, the event must be signed by the server which
owns the user ID in the field. When copying the membership event's `content`
(for profile updates and similar) it is therefore encouraged to exclude this
field in the copy, as otherwise the event might fail event authorization.
Client and server implementations should be aware of the [signing implications](/rooms/v8/#authorization-rules)
of including this field in further events: in particular, the event must be signed by the
server which owns the user ID in the field. When copying the membership event's `content`
(for profile updates and similar) it is therefore encouraged to exclude this field in the
copy, as otherwise the event might fail event authorization.
reason:
x-addedInMatrixVersion: "1.1"
type: string
description: |-
Optional user-supplied text for why their membership has changed. For kicks and bans, this is typically the reason for the kick or ban.
For other membership changes, this is a way for the user to communicate their intent without having to send a message to the room, such
as in a case where Bob rejects an invite from Alice about an upcoming concert, but can't make it that day.
Optional user-supplied text for why their membership has changed. For kicks and bans,
this is typically the reason for the kick or ban. For other membership changes, this is a
way for the user to communicate their intent without having to send a message to the
room, such as in a case where Bob rejects an invite from Alice about an upcoming concert,
but can't make it that day.
Clients are not recommended to show this reason to users when receiving an invite due to the potential for spam and abuse. Hiding the
reason behind a button or other component is recommended.
Clients are not recommended to show this reason to users when receiving an invite due to
the potential for spam and abuse. Hiding the reason behind a button or other component is
recommended.
third_party_invite:
title: ThirdPartyInvite
description: |-
A third-party invite, if this `m.room.member` is the successor to an
[`m.room.third_party_invite`](/client-server-api/#mroomthird_party_invite)
event.
type: object
properties:
display_name:
description: A name which can be displayed to represent the user instead of their third-party identifier
description: |-
A name which can be displayed to represent the user instead of their
third-party identifier
type: string
signed:
description: 'A block of content which has been signed, which servers can use to verify the event. Clients should ignore this.'
properties:
mxid:
description: The invited matrix user ID. Must be equal to the user_id property of the event.
type: string
signatures:
description: 'A single signature from the verifying server, in the format specified by the Signing Events section of the server-server API.'
title: Signatures
type: object
additionalProperties:
type: object
additionalProperties:
type: string
token:
description: The token property of the containing third_party_invite object.
type: string
required:
- mxid
- signatures
- token
title: signed
type: object
$ref: components/signed_third_party_invite.yaml
required:
- display_name
- signed
title: Invite
type: object
required:
- membership
title: EventContent

View file

@ -1,28 +1,56 @@
---
allOf:
- $ref: core-event-schema/state_event.yaml
description: "Acts as an `m.room.member` invite event, where there isn't a target user_id to invite. This event contains a token and a public key whose private key must be used to sign the token. Any user who can present that signature may use this invitation to join the target room."
description: |-
Acts as an `m.room.member` invite event, where there isn't a target user_id to
invite. This event contains a token and a public key whose private key must be
used to sign the token. Any user who can present that signature may use this
invitation to join the target room.
properties:
content:
properties:
display_name:
description: "A user-readable string which represents the user who has been invited. This should not contain the user's third-party ID, as otherwise when the invite is accepted it would leak the association between the matrix ID and the third-party ID."
description: |-
A user-readable string which represents the user who has been invited.
This should not contain the user's third-party ID, as otherwise when
the invite is accepted it would leak the association between the
matrix ID and the third-party ID.
type: string
key_validity_url:
description: "A URL which can be fetched, with querystring public_key=public_key, to validate whether the key has been revoked. The URL must return a JSON object containing a boolean property named 'valid'."
description: |-
A URL which can be fetched, with querystring public_key=public_key, to
validate whether the key has been revoked. The URL must return a JSON
object containing a boolean property named 'valid'.
type: string
format: uri
public_key:
description: A base64-encoded ed25519 key with which token must be signed (though a signature from any entry in public_keys is also sufficient). This exists for backwards compatibility.
description: |-
An Ed25519 key with which the token must be signed (though a signature
from any entry in `public_keys` is also sufficient).
The key is encoded using [Unpadded Base64](/appendices/#unpadded-base64),
using the standard or URL-safe alphabets.
This exists for backwards compatibility.
type: string
public_keys:
description: Keys with which the token may be signed.
items:
properties:
key_validity_url:
description: "An optional URL which can be fetched, with querystring public_key=public_key, to validate whether the key has been revoked. The URL must return a JSON object containing a boolean property named 'valid'. If this URL is absent, the key must be considered valid indefinitely."
description: |-
An optional URL which can be fetched, with querystring
`public_key=<public_key>`, to validate whether the key has been
revoked. The URL must return a JSON object containing a boolean
property named `valid`. If this URL is absent, the key must be
considered valid indefinitely.
type: string
public_key:
description: A base-64 encoded ed25519 key with which token may be signed.
description: |-
An Ed25519 key with which the token may be signed.
The key is encoded using [Unpadded Base64](/appendices/#unpadded-base64),
using the standard or URL-safe alphabets.
type: string
required:
- public_key
@ -35,11 +63,15 @@ properties:
- public_key
type: object
state_key:
description: 'The token, of which a signature must be produced in order to join the room.'
description: |-
The token, of which a signature must be produced in order to join the
room.
type: string
type:
enum:
- m.room.third_party_invite
type: string
title: 'An invitation to a room issued to a third-party identifier, rather than a matrix user ID.'
title: |-
An invitation to a room issued to a third-party identifier, rather than a
matrix user ID.
type: object

View file

@ -1,7 +1,14 @@
---
allOf:
- $ref: core-event-schema/state_event.yaml
description: 'A topic is a short message detailing what is currently being discussed in the room. It can also be used as a way to display extra information about the room, which may not be suitable for the room name. The room topic can also be set when creating a room using `/createRoom` with the `topic` key.'
description: |-
A topic is a short message detailing what is currently being discussed in the room.
It can also be used as a way to display extra information about the room, which may not
be suitable for the room name.
The room topic can also be set when creating a room using `/createRoom` with the `topic` key.'
If the `topic` property is absent, null, or empty then the topic is unset. In other words,
an empty `topic` property effectively resets the room to having no topic.
properties:
content:
properties:

View file

@ -51,6 +51,11 @@ mx-room-id:
url: appendices#room-ids
# regex: "^!"
mx-room-alias:
title: Room Alias
url: appendices#room-aliases
# regex: "^#"
mx-server-name:
title: Server Name
url: appendices#server-name

View file

@ -0,0 +1 @@
https://matrix.org/funding.json