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.

Sign up for GitHub

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

Jump to bottom

MSC3818: Copy room type on upgrade #3818

Merged
merged 10 commits into from
Jul 31, 2022
Merged

MSC3818: Copy room type on upgrade #3818

Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
2439ceb
add proposal xxxx-copy-room-type-on-upgrade.md
Mikaela May 18, 2022
4cd1d73
MSC 3818: add MSC number
Mikaela May 18, 2022
ffb4274
msc3818: remove template text from beginning
Mikaela May 18, 2022
0b8d037
3818-copy-room-type-on-upgrade: refer to the current version of spec …
Mikaela May 18, 2022
594d9a1
Update proposals/3818-copy-room-type-on-upgrade.md
Mikaela May 18, 2022
d6ae0bb
Update proposals/3818-copy-room-type-on-upgrade.md
Mikaela May 18, 2022
d85ba65
3818-copy-room-type-on-upgrade.md: specify v1.2 in links
Mikaela May 18, 2022
2598da2
3818-copy-room-type-on-upgrade.md: correct link for MSC3588
Mikaela May 18, 2022
b2b1889
MSC3818: note potential issue when state events are needed
Mikaela May 19, 2022
1242850
MSC3818: note an alternative of all room types needing an MSC
Mikaela May 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions proposals/3818-copy-room-type-on-upgrade.md
View file
Open in desktop
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.