From 5ecd1d5d577d7b9c5a158b2a00f2be9e12ca8dd3 Mon Sep 17 00:00:00 2001 From: Matthias Ahouansou Date: Sat, 6 Jul 2024 16:05:50 +0100 Subject: [PATCH 1/2] Proposal to update space state events on room upgrade Signed-off-by: Matthias Ahouansou --- ...4168-update-space-state-on-room-upgrade.md | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 proposals/4168-update-space-state-on-room-upgrade.md diff --git a/proposals/4168-update-space-state-on-room-upgrade.md b/proposals/4168-update-space-state-on-room-upgrade.md new file mode 100644 index 000000000..e64a617c6 --- /dev/null +++ b/proposals/4168-update-space-state-on-room-upgrade.md @@ -0,0 +1,46 @@ +# MSC4168: Update `m.space.*` state on room upgrade + +When a [room upgrade](https://spec.matrix.org/v1.11/client-server-api/#room-upgrades) is performed, +many state events are copied over to the new room, to minimize the amount of work the user has to do +after the upgrade. However, the spec doesn't currently recommend that `m.space.child` or `m.space.parent` +be copied over, as well as these events being updated in other rooms. + +## Proposal + +When a room upgrade is performed, servers SHOULD replicate `m.space.child` and `m.space.parent` state +in the new room. + +In addition, `m.space.child` and `m.space.parent` events in other rooms, where the caller of `/upgrade` +has the permission to do so, servers SHOULD send a new state event for the old room, removing the `via` field +from it, and send a new event of the same type, with `state_key` being the new room ID, and `via` just +being the server of the sender user. Like when these events are copied into the upgraded room, the `sender` +should be set to the user calling the endpoint. + +## Potential issues + +This proposal does not attempt to update `m.space.*` state in rooms where the user upgrading the room +is not able to update them, as this not only likely requires something like +[MSC4049](https://github.com/matrix-org/matrix-spec-proposals/pull/4049), but also adds other additional +complications (e.g. which server should update the state?). + +Users may also not want to update events in other rooms. Hopefully this proposal can be used to determine +if there is a use-case for not updating events in other rooms. If there is one, then a query parameter can +be added to toggle this feature. + +## Alternatives + +As above, utilizing [MSC4049](https://github.com/matrix-org/matrix-spec-proposals/pull/4049) to update +`m.space.*` events in other rooms could be an alternative, but due to additional complications in addition +to requiring this MSC to be merged, it is deemed as not the best solution (for now). + +## Security considerations + +None considered. + +## Unstable prefix + +None required, as currently no new endpoints or fields are being proposed. + +## Dependencies + +None. From 01faedbf66b262a86c9b4ad11d05e85910569210 Mon Sep 17 00:00:00 2001 From: Matthias Ahouansou Date: Mon, 1 Dec 2025 14:02:33 +0000 Subject: [PATCH 2/2] events depend on room type + break down operations into bullet points Co-authored-by: Andrew Morgan --- ...4168-update-space-state-on-room-upgrade.md | 25 +++++++++++++------ 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/proposals/4168-update-space-state-on-room-upgrade.md b/proposals/4168-update-space-state-on-room-upgrade.md index e64a617c6..aaaae31b7 100644 --- a/proposals/4168-update-space-state-on-room-upgrade.md +++ b/proposals/4168-update-space-state-on-room-upgrade.md @@ -7,14 +7,23 @@ be copied over, as well as these events being updated in other rooms. ## Proposal -When a room upgrade is performed, servers SHOULD replicate `m.space.child` and `m.space.parent` state -in the new room. - -In addition, `m.space.child` and `m.space.parent` events in other rooms, where the caller of `/upgrade` -has the permission to do so, servers SHOULD send a new state event for the old room, removing the `via` field -from it, and send a new event of the same type, with `state_key` being the new room ID, and `via` just -being the server of the sender user. Like when these events are copied into the upgraded room, the `sender` -should be set to the user calling the endpoint. +In the following sentences, "relevant space state events" refer to `m.space.parent` events for all +room types, in addition to `m.space.child` events for rooms with a type of +[`m.space`](https://spec.matrix.org/v1.16/client-server-api/#types). + +When a room upgrade is performed, servers SHOULD copy relevant space state events from the old room +to the new room. The sender field in the new event should be set to the user who performed the +upgrade. + +In addition, servers SHOULD update relevant space state events in rooms that reference the old room +(in their `state_key` field). Note that this will only be possible in rooms where the upgrading +user (or any other user on the same homeserver, if the implementation decides to use any user it +can) has the power to do so. + +The `via` field of each new state event SHOULD only contain the server name of the server, +regardless of its previous content. This is because the server's listed in the previous `via` field +may not have joined the upgraded room yet, and thus servers may not be able to join through them. + ## Potential issues