Room Upgrades

From time to time, a room may need to be upgraded to a different room version for a variety of reasons. This module defines a way for rooms to upgrade to a different room version when needed.

Events

{
  "content": {
    "body": "This room has been replaced",
    "replacement_room": "!newroom:example.org"
  },
  "event_id": "$143273582443PhrSn:example.org",
  "origin_server_ts": 1432735824653,
  "room_id": "!jEsUZKDJdhlrceRyVU:example.org",
  "sender": "@example:example.org",
  "state_key": "",
  "type": "m.room.tombstone",
  "unsigned": {
    "age": 1234
  }
}

Client behaviour

Clients which understand m.room.tombstone events and the predecessor field on m.room.create events should communicate to the user that the room was upgraded. One way of accomplishing this would be hiding the old room from the user’s room list and showing banners linking between the old and new room - ensuring that permalinks work when referencing the old room. Another approach may be to virtually merge the rooms such that the old room’s timeline seamlessly continues into the new timeline without the user having to jump between the rooms.

{
  "new_version": "2"
}

{
  "replacement_room": "!newroom:example.org"
}

{
  "errcode": "M_UNSUPPORTED_ROOM_VERSION",
  "error": "This server does not support that room version"
}

{
  "errcode": "M_FORBIDDEN",
  "error": "You cannot upgrade this room"
}

Server behaviour

When the client requests to upgrade a known room to a known version, the server:

1. Checks that the user has permission to send m.room.tombstone events in the room.

2. [Changed in v1.4] Creates a replacement room with a m.room.create event containing a predecessor field, the applicable room_version, and a type field which is copied from the predecessor room. If no type is set on the previous room, no type is specified on the new room’s create event either.

3. Replicates transferable state events to the new room. The exact details for what is transferred is left as an implementation detail, however the recommended state events to transfer are:

   • m.room.server_acl
   • m.room.encryption
   • m.room.name
   • m.room.avatar
   • m.room.topic
   • m.room.guest_access
   • m.room.history_visibility
   • m.room.join_rules
   • m.room.power_levels

   Membership events should not be transferred to the new room due to technical limitations of servers not being able to impersonate people from other homeservers. Additionally, servers should not transfer state events which are sensitive to who sent them, such as events outside of the Matrix namespace where clients may rely on the sender to match certain criteria.

4. Moves any local aliases to the new room.

5. Sends a m.room.tombstone event to the old room to indicate that it is not intended to be used any further.

6. If possible, the power levels in the old room should also be modified to prevent sending of events and inviting new users. For example, setting events_default and invite to the greater of 50 and users_default + 1.

When a user joins the new room, the server should automatically transfer/replicate some of the user’s personalized settings such as notifications, tags, etc.