MSC3818: Copy room type on upgrade (#3818)
* add proposal xxxx-copy-room-type-on-upgrade.md Signed-off-by: Aminda Suomalainen <suomalainen+git@mikaela.info> * MSC 3818: add MSC number Signed-off-by: Aminda Suomalainen <suomalainen+git@mikaela.info> * msc3818: remove template text from beginning Signed-off-by: Aminda Suomalainen <suomalainen+git@mikaela.info> * 3818-copy-room-type-on-upgrade: refer to the current version of spec and what to change Signed-off-by: Aminda Suomalainen <suomalainen+git@mikaela.info> * Update proposals/3818-copy-room-type-on-upgrade.md Signed-off-by: Aminda Suomalainen <suomalainen+git@mikaela.info> Co-authored-by: Andy Balaam <mail@artificialworlds.net> * Update proposals/3818-copy-room-type-on-upgrade.md Signed-off-by: Aminda Suomalainen <suomalainen+git@mikaela.info> Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com> * 3818-copy-room-type-on-upgrade.md: specify v1.2 in links Signed-off-by: Aminda Suomalainen <suomalainen+git@mikaela.info> * 3818-copy-room-type-on-upgrade.md: correct link for MSC3588 Signed-off-by: Aminda Suomalainen <suomalainen+git@mikaela.info> * MSC3818: note potential issue when state events are needed * MSC3818: note an alternative of all room types needing an MSC Co-authored-by: Andy Balaam <mail@artificialworlds.net> Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>travis/msc/welcome-message
parent
0f067f1548
commit
43a3620edf
@ -0,0 +1,48 @@
|
||||
# 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.
|
||||
|
||||
|
||||
## 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):
|
||||
|
||||
> 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
|
||||
|
||||
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
|
||||
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.
|
Loading…
Reference in New Issue