-
Notifications
You must be signed in to change notification settings - Fork 403
MSC3818: Copy room type on upgrade #3818
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
Changes from 4 commits
2439ceb
4cd1d73
ffb4274
0b8d037
594d9a1
d6ae0bb
d85ba65
2598da2
b2b1889
1242850
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,41 @@ | ||
# MSC3818: Copy room type on upgrade | ||
|
||
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
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note that clients still cannot rely on the homeserver copying over the 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 over to the new room. Otherwise | ||
clients cannot trust that to happen and Spaces or MSC3588 Story rooms may incorrectly become normal | ||
rooms breaking user-experience. | ||
Mikaela marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
The Spec currently specfies this in [section 11.32.3. server behaviour](https://spec.matrix.org/v1.2/client-server-api/#server-behaviour-16): | ||
|
||
> 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 if it was set in the previous room, and the applicable `room_version`. | ||
Mikaela marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
|
||
## Potential issues | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 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. |
||
|
||
Non-applicable. | ||
Mikaela marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Alternatives | ||
|
||
Non-applicable. | ||
|
||
## Security considerations | ||
|
||
Non-applicable. | ||
|
||
## Unstable prefix | ||
|
||
Non-applicable. | ||
|
||
## Dependencies | ||
|
||
Non-applicable. | ||
Mikaela marked this conversation as resolved.
Show resolved
Hide resolved
|
Uh oh!
There was an error while loading. Please reload this page.