From ba4252afe5681f6ddf06d96cff4b90cc682f3914 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Thu, 20 Mar 2025 16:20:51 +0100 Subject: [PATCH 1/5] Clarify the meaning of "public spaces" Relates to: #633 Signed-off-by: Johannes Marbach --- content/client-server-api/modules/spaces.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/content/client-server-api/modules/spaces.md b/content/client-server-api/modules/spaces.md index 11734ac3..0c81c61e 100644 --- a/content/client-server-api/modules/spaces.md +++ b/content/client-server-api/modules/spaces.md @@ -2,8 +2,8 @@ {{% added-in v="1.2" %}} -Often used to group rooms of similar subject matter (such as a public "Official -matrix.org rooms" space or personal "Work stuff" space), spaces are a way to +Often used to group rooms of similar subject matter (such as an "Official +matrix.org rooms" space or a "Work stuff" space), spaces are a way to organise rooms while being represented as rooms themselves. A space is defined by the [`m.space` room type](#types), making it known as a @@ -19,10 +19,10 @@ go a step further and explicitly ignore notification counts on space-rooms. Membership of a space is defined and controlled by the existing mechanisms which govern a room: [`m.room.member`](#mroommember), [`m.room.history_visibility`](#mroomhistory_visibility), -and [`m.room.join_rules`](#mroomjoin_rules). Public spaces are encouraged to have -a similar setup to public rooms: `world_readable` history visibility, published -canonical alias, and suitably public `join_rule`. Invites, including third-party -invites, still work just as they do in normal rooms as well. +and [`m.room.join_rules`](#mroomjoin_rules). Canonical aliases and invites, including +third-party invites, still work just as they do in normal rooms as well. Furthermore, +spaces can also be published in the [room directory](#room-directory) to make them +discoverable. All other aspects of regular rooms are additionally carried over, such as the ability to set arbitrary state events, hold room account data, etc. Spaces are @@ -87,10 +87,9 @@ the state of `#space:example.org` would consist of: } ``` -No state events in the child rooms themselves would be required (though they -can also be present). This allows for users -to define personal/private spaces to organise their own rooms without needing explicit -permission from the room moderators/admins. +No state events in the child rooms themselves would be required (though they can also +be present). This allows for users to define spaces without needing explicit permission +from the room moderators/admins. Child rooms can be removed from a space by omitting the `via` key of `content` on the relevant state event, such as through redaction or otherwise clearing the `content`. From 339ea6be12f4b253aa15421aa4c1a0747e8b461d Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Thu, 20 Mar 2025 16:32:19 +0100 Subject: [PATCH 2/5] Add changelog --- changelogs/client_server/newsfragments/2109.clarification | 1 + 1 file changed, 1 insertion(+) create mode 100644 changelogs/client_server/newsfragments/2109.clarification diff --git a/changelogs/client_server/newsfragments/2109.clarification b/changelogs/client_server/newsfragments/2109.clarification new file mode 100644 index 00000000..5aa7de17 --- /dev/null +++ b/changelogs/client_server/newsfragments/2109.clarification @@ -0,0 +1 @@ +Spaces are subject to the same access mechanisms as rooms. From dd8aaa0d66aa6947f883f8c7e9df8fec9450e98c Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 21 May 2025 22:57:43 +0200 Subject: [PATCH 3/5] Update content/client-server-api/modules/spaces.md --- content/client-server-api/modules/spaces.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/client-server-api/modules/spaces.md b/content/client-server-api/modules/spaces.md index 0c81c61e..a565baed 100644 --- a/content/client-server-api/modules/spaces.md +++ b/content/client-server-api/modules/spaces.md @@ -19,9 +19,9 @@ go a step further and explicitly ignore notification counts on space-rooms. Membership of a space is defined and controlled by the existing mechanisms which govern a room: [`m.room.member`](#mroommember), [`m.room.history_visibility`](#mroomhistory_visibility), -and [`m.room.join_rules`](#mroomjoin_rules). Canonical aliases and invites, including +and [`m.room.join_rules`](/client-server-api##mroomjoin_rules). Canonical aliases and invites, including third-party invites, still work just as they do in normal rooms as well. Furthermore, -spaces can also be published in the [room directory](#room-directory) to make them +spaces can also be published in the [room directory](/client-server-api#published-room-directory) to make them discoverable. All other aspects of regular rooms are additionally carried over, such as the From 20828ee3543bf902a4c5152191c76e5d3ad9555c Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 21 May 2025 22:58:24 +0200 Subject: [PATCH 4/5] Update content/client-server-api/modules/spaces.md --- content/client-server-api/modules/spaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/client-server-api/modules/spaces.md b/content/client-server-api/modules/spaces.md index a565baed..611f0a6a 100644 --- a/content/client-server-api/modules/spaces.md +++ b/content/client-server-api/modules/spaces.md @@ -18,7 +18,7 @@ In the default power level structure, this would be `100`. Clients might wish to go a step further and explicitly ignore notification counts on space-rooms. Membership of a space is defined and controlled by the existing mechanisms which -govern a room: [`m.room.member`](#mroommember), [`m.room.history_visibility`](#mroomhistory_visibility), +govern a room: [`m.room.member`](/client-server-api#mroommember), [`m.room.history_visibility`](/client-server-api#mroomhistory_visibility), and [`m.room.join_rules`](/client-server-api##mroomjoin_rules). Canonical aliases and invites, including third-party invites, still work just as they do in normal rooms as well. Furthermore, spaces can also be published in the [room directory](/client-server-api#published-room-directory) to make them From d05a26b24efddddb9ba9963854bb0d76aa0fc462 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Wed, 21 May 2025 23:00:48 +0200 Subject: [PATCH 5/5] Update content/client-server-api/modules/spaces.md --- content/client-server-api/modules/spaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/client-server-api/modules/spaces.md b/content/client-server-api/modules/spaces.md index 611f0a6a..7de41459 100644 --- a/content/client-server-api/modules/spaces.md +++ b/content/client-server-api/modules/spaces.md @@ -19,7 +19,7 @@ go a step further and explicitly ignore notification counts on space-rooms. Membership of a space is defined and controlled by the existing mechanisms which govern a room: [`m.room.member`](/client-server-api#mroommember), [`m.room.history_visibility`](/client-server-api#mroomhistory_visibility), -and [`m.room.join_rules`](/client-server-api##mroomjoin_rules). Canonical aliases and invites, including +and [`m.room.join_rules`](/client-server-api#mroomjoin_rules). Canonical aliases and invites, including third-party invites, still work just as they do in normal rooms as well. Furthermore, spaces can also be published in the [room directory](/client-server-api#published-room-directory) to make them discoverable.