Merge 6183f2410f into ca9c376076

.github/workflows/main.yml

@@ -284,11 +284,10 @@ jobs:
           npm i
           npm run get-proposals
       - name: "⚙️ hugo"
-        env:
-          HUGO_PARAMS_VERSION_STATUS: "historical"
         # Create a baseURL like `/v1.2` out of the `v1.2` tag
         run: |
-          hugo --baseURL "/${GITHUB_REF/refs\/tags\//}" -d "spec"
+          echo -e '[params.version]\nstatus="historical"' > historical.toml
+          hugo --config config.toml,historical.toml --baseURL "/${GITHUB_REF/refs\/tags\//}" -d "spec"
 
       - name: "📥 Spec definition download"
         uses: actions/download-artifact@v4

changelogs/client_server/newsfragments/2095.feature

@@ -1 +0,0 @@
-Add `m.topic` content block to enable rich text in `m.room.topic` events as per [MSC3765](https://github.com/matrix-org/matrix-spec-proposals/pull/3765).

changelogs/client_server/newsfragments/2101.clarification

@@ -1 +0,0 @@
-"Public" rooms in profile look-ups are defined through their join rule and history visibility.

changelogs/client_server/newsfragments/2102.clarification

@@ -1 +0,0 @@
-"Public" rooms in user directory queries are defined through their join rule and history visibility.

changelogs/client_server/newsfragments/2106.clarification

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

changelogs/client_server/newsfragments/2107.clarification

@@ -1 +0,0 @@
-"Public" rooms have no specific meaning with respect to moderation policy lists.

changelogs/client_server/newsfragments/2108.clarification

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

changelogs/internal/newsfragments/2123.clarification

@@ -1 +0,0 @@
-Fix the historical info box when generating the historical spec in CI.

changelogs/server_server/newsfragments/2095.feature

@@ -1 +0,0 @@
-Add `m.topic` content block to enable rich text in `m.room.topic` events as per [MSC3765](https://github.com/matrix-org/matrix-spec-proposals/pull/3765).

changelogs/server_server/newsfragments/2100.clarification

@@ -1 +0,0 @@
-Clarify that auth event of `content.join_authorised_via_users_server` is only necessary for `m.room.member` with a `membership` of `join`.

content/client-server-api/_index.md

@@ -2862,15 +2862,10 @@ re-invited.
 
 #### Server behaviour
 
-Homeservers MUST at a minimum allow profile look-up for users who are
+Homeservers MUST at a minimum allow profile look-up for:
-visible to the requester based on their membership in rooms known to the
-homeserver. This means:
 
 -   users that share a room with the requesting user
--   users who are joined to rooms known to the homeserver that have a
+-   users that reside in public rooms known to the homeserver
-    `public` [join rule](#mroomjoin_rules)
--   users who are joined to rooms known to the homeserver that have a
-    `world_readable` [history visibility](#room-history-visibility)
 
 In all other cases, homeservers MAY deny profile look-up by responding with
 403 and an error code of `M_FORBIDDEN`.

content/client-server-api/modules/moderation_policies.md

@@ -18,9 +18,8 @@ the entity making the decisions on filtering is best positioned to
 interpret the rules how it sees fit.
 
 Moderation policy lists are stored as room state events. There are no
-restrictions on how the rooms can be configured in terms of
+restrictions on how the rooms can be configured (they could be public,
-[join rules](#mroomjoin_rules), [history visibility](#room-history-visibility),
+private, encrypted, etc).
-encryption, etc.
 
 There are currently 3 kinds of entities which can be affected by rules:
 `user`, `server`, and `room`. All 3 are described with

content/client-server-api/modules/presence.md

@@ -68,7 +68,5 @@ will cause the server to automatically set their presence to `online`.
 
 #### Security considerations
 
-Presence information is published to all users who share a room with the
+Presence information is shared with all users who share a room with the
-target user. If the target user is a member of a room with a `public`
+target user. In large public rooms this could be undesirable.
-[join rule](#mroomjoin_rules), any other user in the federation is
-able to gain access to the target user's presence. This could be undesirable.

content/client-server-api/modules/search.md

@@ -26,10 +26,9 @@ on certain keys of certain event types.
 
 The supported keys to search over are:
 
--   `content.body` in [`m.room.message`](/client-server-api/#mroommessage)
+-   `content.body` in `m.room.message`
--   `content.name` in [`m.room.name`](/client-server-api/#mroomname)
+-   `content.name` in `m.room.name`
--   In [`m.room.topic`](/client-server-api/#mroomtopic), `content.topic`
+-   `content.topic` in `m.room.topic`
-    as well as the `body` of the `text/plain` representation in `content['m.topic']`.
 
 The search will *not* include rooms that are end to end encrypted.
 

content/client-server-api/modules/voip_events.md

@@ -202,13 +202,11 @@ 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
+Clients should consider an incoming call if they see a non-expired invite event where the `invitee` field is either
-where the `invitee` field is either absent or equal to their user's Matrix ID.
+absent or equal to their user's Matrix ID, however they should evaluate whether or not to ring based on their
-They should, however, evaluate whether or not to ring based on their user's trust
+user's trust relationship with the callers and/or where the call was placed. As a starting point, it is
-relationship with the callers and/or where the call was placed. As a starting
+suggested that clients ignore call invites from users in public rooms. It is strongly recommended that
-point, it is RECOMMENDED that clients ignore call invites in rooms with a
+when clients do not ring for an incoming call invite, they still display the call invite in the room and
-[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

content/server-server-api.md

@@ -544,8 +544,8 @@ the following subset of the room state:
       `third_party_invite` property, the current
       `m.room.third_party_invite` event with `state_key` matching
       `content.third_party_invite.signed.token`, if any.
-    - If `membership` is `join`, `content.join_authorised_via_users_server`
+    - If `content.join_authorised_via_users_server` is present,
-      is present, and the [room version supports restricted rooms](/rooms/#feature-matrix),
+      and the [room version supports restricted rooms](/rooms/#feature-matrix),
       then the `m.room.member` event with `state_key` matching
       `content.join_authorised_via_users_server`.
 

data/api/client-server/create_room.yaml

@@ -109,17 +109,15 @@ paths:
                 name:
                   type: string
                   description: |-
-                    If this is included, an [`m.room.name`](/client-server-api/#mroomname) event
+                    If this is included, an `m.room.name` event will be sent
-                    will be sent into the room to indicate the name for the room.
+                    into the room to indicate the name of the room. See Room
-                    This overwrites any [`m.room.name`](/client-server-api/#mroomname)
+                    Events for more information on `m.room.name`.
-                    event in `initial_state`.
                 topic:
                   type: string
                   description: |-
-                    If this is included, an [`m.room.topic`](/client-server-api/#mroomtopic)
+                    If this is included, an `m.room.topic` event will be sent
-                    event with a `text/plain` mimetype will be sent into the room
+                    into the room to indicate the topic for the room. See Room
-                    to indicate the topic for the room. This overwrites any
+                    Events for more information on `m.room.topic`.
-                    [`m.room.topic`](/client-server-api/#mroomtopic) event in `initial_state`.
                 invite:
                   type: array
                   description: |-

data/api/client-server/definitions/public_rooms_chunk.yaml

@@ -33,9 +33,7 @@ properties:
     example: "!abcdefg:example.org"
   topic:
     type: string
-    description: |-
+    description: The topic of the room, if any.
-      The plain text topic of the room. Omitted if no `text/plain` mimetype
-      exists in [`m.room.topic`](/client-server-api/#mroomtopic).
     example: "All things general"
   world_readable:
     type: boolean

data/api/client-server/users.yaml

@@ -20,17 +20,10 @@ paths:
     post:
       summary: Searches the user directory.
       description: |-
-        Performs a search for users. The homeserver may determine which
+        Performs a search for users. The homeserver may
-        subset of users are searched. However, the homeserver MUST at a
+        determine which subset of users are searched, however the homeserver
-        minimum consider users who are visible to the requester based
+        MUST at a minimum consider the users the requesting user shares a
-        on their membership in rooms known to the homeserver. This means:
+        room with and those who reside in public rooms (known to the homeserver).
-
-        -   users that share a room with the requesting user
-        -   users who are joined to rooms known to the homeserver that have a
-            `public` [join rule](#mroomjoin_rules)
-        -   users who are joined to rooms known to the homeserver that have a
-            `world_readable` [history visibility](#room-history-visibility)
-        
         The search MUST consider local users to the homeserver, and SHOULD
         query remote users as part of the search.
 

data/event-schemas/examples/m.room.topic.yaml

@@ -3,14 +3,6 @@
   "type": "m.room.topic",
   "state_key": "",
   "content": {
-    "m.topic": {
+    "topic": "A room topic"
-      "m.text": [ {
-        "mimetype": "text/html",
-        "body": "An <em>interesting</em> room topic"
-      }, {
-        "body": "An interesting room topic"
-      }]
-    },
-    "topic": "An interesting room topic"
   }
 }

data/event-schemas/schema/components/m_text_content_block.yaml

@@ -1,28 +0,0 @@
-type: array
-description: |-
-  An ordered array of textual representations in different mimetypes.
-
-  Senders SHOULD specify at least one representation and SHOULD always
-  include a plaintext representation.
-  
-  Receivers SHOULD use the first representation in the array that
-  they understand.
-title: TextContentBlock
-items:
-  type: object
-  title: TextualRepresentation
-  properties:
-    mimetype:
-      type: string
-      description: The mimetype. Defaults to `text/plain` if omitted.
-      example: "text/html"
-    body:
-      type: string
-      description: |-
-        The string content.
-
-        Clients SHOULD validate and sanitize the content as they do
-        for rich content associated with [`msgtype`](/client-server-api/#mroommessage-msgtypes)
-        of [`m.room.message`](/client-server-api/#mroommessage).
-  required:
-  - body

data/event-schemas/schema/m.room.topic.yaml

@@ -1,41 +1,20 @@
 ---
 allOf:
   - $ref: core-event-schema/state_event.yaml
-description: |-
+description: |- 
-    A topic is a short message detailing what is currently being discussed
+    A topic is a short message detailing what is currently being discussed in the room.
-    in the room.  It can also be used as a way to display extra information
+    It can also be used as a way to display extra information about the room, which may not
-    about the room, which may not be suitable for the room name. The room
+    be suitable for the room name.
-    topic can also be set when creating a room using
+    The room topic can also be set when creating a room using `/createRoom` with the `topic` key.'
-    [`/createRoom`](client-server-api/#post_matrixclientv3createroom), either
+    
-    with the `topic` key or by specifying a full event in `initial_state`.
-  
     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.
-
-    In order to prevent formatting abuse in room topics, clients SHOULD
-    limit the length of topics during both entry and display, for instance,
-    by capping the number of displayed lines. Additionally, clients SHOULD
-    ignore things like headings and enumerations (or format them as regular
-    text).
 properties:
   content:
     properties:
       topic:
-        description: |-
+        description: The topic text.
-          The topic in plain text.
-
-          This SHOULD duplicate the content of the `text/plain`
-          representation in `m.topic` if any exists.
         type: string
-      m.topic:
-        type: object
-        title: TopicContentBlock
-        x-addedInMatrixVersion: "1.15"
-        description: |-
-          Textual representation of the room topic in different mimetypes.
-        properties:
-          m.text:
-            $ref: components/m_text_content_block.yaml
     required:
       - topic
     type: object