Compare commits

...

5 commits

Author SHA1 Message Date
Johannes Marbach c3de68659a
Merge 69aba13aa7 into 65b1db721d 2025-04-15 18:24:49 +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
Johannes Marbach 69aba13aa7 Add changelog 2025-03-20 11:05:24 +01:00
Johannes Marbach 53424874c9 Clarify the meaning of "public rooms" for call invites
Relates to: #633
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
2025-03-20 11:02:48 +01:00
7 changed files with 62 additions and 9 deletions

View file

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

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

@ -0,0 +1 @@
"Public" rooms with respect to call invites are defined through their join rule.

View file

@ -202,11 +202,13 @@ specific user, and should be set to the Matrix user ID of that user. Invites
without an `invitee` field are defined to be intended for any member of the
room other than the sender of the event.
Clients should consider an incoming call if they see a non-expired invite event where the `invitee` field is either
absent or equal to their user's Matrix ID, however they should evaluate whether or not to ring based on their
user's trust relationship with the callers and/or where the call was placed. As a starting point, it is
suggested that clients ignore call invites from users in public rooms. It is strongly recommended that
when clients do not ring for an incoming call invite, they still display the call invite in the room and
Clients should consider an incoming call if they see a non-expired invite event
where the `invitee` field is either absent or equal to their user's Matrix ID.
They should, however, evaluate whether or not to ring based on their user's trust
relationship with the callers and/or where the call was placed. As a starting
point, it is RECOMMENDED that clients ignore call invites in rooms with a
[join rule](#mroomjoin_rules) of `public`. When clients suppress ringing for an
incoming call invite, they SHOULD still display the call invite in the room and
annotate that it was ignored.
##### Glare

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

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

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