From 5ecd1d5d577d7b9c5a158b2a00f2be9e12ca8dd3 Mon Sep 17 00:00:00 2001 From: Matthias Ahouansou Date: Sat, 6 Jul 2024 16:05:50 +0100 Subject: [PATCH] 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.