Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3818: Copy room type on upgrade #3818

Merged
merged 10 commits into from
Jul 31, 2022
48 changes: 48 additions & 0 deletions proposals/3818-copy-room-type-on-upgrade.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
# MSC3818: Copy room type on upgrade
Mikaela marked this conversation as resolved.
Show resolved Hide resolved

Unless the room upgrade API specifies that room type must be copied over, clients cannot rely on
rooms staying the same type leading to trouble.
Comment on lines +3 to +4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that clients still cannot rely on the homeserver copying over the type field unless the homeserver advertises support for the spec version which this MSC makes it into. It may be worth mentioning that under the Unstable Prefix header (even though this MSC doesn't specify any unstable prefixes) or perhaps adding a Client Considerations header.

Clients may consider waiting until the supported spec version is advertised before showing a button, or perhaps prompt users with an "Are you sure?". Users who are aware of whether their homeserver has implemented experimental support for the feature can carry on ahead, whilst the casual user would be warned against potentially breaking the room.



## Proposal

This MSC proposes that the room upgade API MUST copy the [room type](https://spec.matrix.org/v1.2/client-server-api/#types)
over to the new room. Otherwise clients cannot trust that to happen and [Spaces](https://spec.matrix.org/v1.2/client-server-api/#spaces)
or [MSC3588](https://github.com/matrix-org/matrix-spec-proposals/pull/3588) Story rooms may incorrectly become
normal rooms breaking user-experience.

The Spec currently specfies this in [section 11.32.3. server behaviour](https://spec.matrix.org/v1.2/client-server-api/#server-behaviour-16):
Comment on lines +9 to +14
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This MSC proposes that the room upgade API MUST copy the [room type](https://spec.matrix.org/v1.2/client-server-api/#types)
over to the new room. Otherwise clients cannot trust that to happen and [Spaces](https://spec.matrix.org/v1.2/client-server-api/#spaces)
or [MSC3588](https://github.com/matrix-org/matrix-spec-proposals/pull/3588) Story rooms may incorrectly become
normal rooms breaking user-experience.
The Spec currently specfies this in [section 11.32.3. server behaviour](https://spec.matrix.org/v1.2/client-server-api/#server-behaviour-16):
This MSC proposes that the room upgade API MUST copy the [room type](https://spec.matrix.org/v1.3/client-server-api/#types)
over to the new room. Otherwise clients cannot trust that to happen and [Spaces](https://spec.matrix.org/v1.3/client-server-api/#spaces)
or [MSC3588](https://github.com/matrix-org/matrix-spec-proposals/pull/3588) Story rooms may incorrectly become
normal rooms breaking user-experience.
The Spec currently specfies this in [section 11.32.3. server behaviour](https://spec.matrix.org/v1.3/client-server-api/#server-behaviour-16):

Just so we have the latest state available. The anchor points continue to work on the v1.3 versions of each link.


> 2. Creates a replacement room with a `m.room.create` event containing a `predecessor` field and the applicable `room_version`.

It becomes:

> 2. Creates a replacement room with a `m.room.create` event containing a `predecessor` field, a
> `type` field set to what it was in the previous room (if it was set), and the applicable `room_version`.


## Potential issues
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another potential issue is that this will prevent a room from ever being upgraded from one type to another. For instance, if you had a room on com.example.my_feature.v1, it could not be upgraded to a com.example.my_feature.v2-type room.

Arguably though, this could be worked around by manually upgrading the room (create a new room, copy state over, send a tombstone in the old room). And I would consider the above an edge case.


Some room types such as Spaces also require copying over state events as a part of the update progress,
in case of Spaces, `m.space.child` events. However as that can be changed later and done by the client,
it's out of scope for this MSC.

## Alternatives

A suggested alternative is having every room type specify their own update process if they use other
room types. However this would complicate the MSC process with even simple client-side proposals
requiring also a server-side implementation. This could also result in room types dependent on a
Mikaela marked this conversation as resolved.
Show resolved Hide resolved
particular server software or discourage using Matrix for a smaller project where an MSC wasn't
otherwise consider necessary.

## Security considerations

Non-applicable.

## Unstable prefix

Non-applicable.

## Dependencies

Non-applicable.