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
-visible to the requester based on their membership in rooms known to the
-homeserver. This means:
+Homeservers MUST at a minimum allow profile look-up for:
 
 -   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)
+-   users that reside in public rooms known to the homeserver
 
 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
-[join rules](#mroomjoin_rules), [history visibility](#room-history-visibility),
-encryption, etc.
+restrictions on how the rooms can be configured (they could be public,
+private, encrypted, 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
-target user. If the target user is a member of a room with a `public`
-[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.
+Presence information is shared with all users who share a room with the
+target user. In large public rooms 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.name` in [`m.room.name`](/client-server-api/#mroomname)
--   In [`m.room.topic`](/client-server-api/#mroomtopic), `content.topic`
-    as well as the `body` of the `text/plain` representation in `content['m.topic']`.
+-   `content.body` in `m.room.message`
+-   `content.name` in `m.room.name`
+-   `content.topic` in `m.room.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
-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
+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
 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`
-      is present, and the [room version supports restricted rooms](/rooms/#feature-matrix),
+    - If `content.join_authorised_via_users_server` is present,
+      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
-                    will be sent into the room to indicate the name for the room.
-                    This overwrites any [`m.room.name`](/client-server-api/#mroomname)
-                    event in `initial_state`.
+                    If this is included, an `m.room.name` event will be sent
+                    into the room to indicate the name of the room. See Room
+                    Events for more information on `m.room.name`.
                 topic:
                   type: string
                   description: |-
-                    If this is included, an [`m.room.topic`](/client-server-api/#mroomtopic)
-                    event with a `text/plain` mimetype will be sent into the room
-                    to indicate the topic for the room. This overwrites any
-                    [`m.room.topic`](/client-server-api/#mroomtopic) event in `initial_state`.
+                    If this is included, an `m.room.topic` event will be sent
+                    into the room to indicate the topic for the room. See Room
+                    Events for more information on `m.room.topic`.
                 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: |-
-      The plain text topic of the room. Omitted if no `text/plain` mimetype
-      exists in [`m.room.topic`](/client-server-api/#mroomtopic).
+    description: The topic of the room, if any.
     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
-        subset of users are searched. However, the homeserver MUST at a
-        minimum consider users who are 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
-            `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)
-        
+        Performs a search for users. The homeserver may
+        determine which subset of users are searched, however the homeserver
+        MUST at a minimum consider the users the requesting user shares a
+        room with and those who reside in public rooms (known to the homeserver).
         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": {
-      "m.text": [ {
-        "mimetype": "text/html",
-        "body": "An <em>interesting</em> room topic"
-      }, {
-        "body": "An interesting room topic"
-      }]
-    },
-    "topic": "An interesting room topic"
+    "topic": "A 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: |-
-    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`](client-server-api/#post_matrixclientv3createroom), either
-    with the `topic` key or by specifying a full event in `initial_state`.
-  
+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.
-
-    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: |-
-          The topic in plain text.
-
-          This SHOULD duplicate the content of the `text/plain`
-          representation in `m.topic` if any exists.
+        description: The topic text.
         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