mirror of
https://github.com/matrix-org/matrix-spec
synced 2025-12-25 10:28:37 +01:00
f97d2944ae
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
* Placeholder * i++ * Room version 12 Template out a v12 room version Make v12 default, per MSC4304 Update PDU checks and auth event selection per MSC4291 Describe new room_id format per MSC4291 Move v6 depth definition to a component for easier referencing Move room_id to a component to prep for v12, per MSC4291 Create and use a new room_id component for v12+ per MSC4291 Reflect auth events selection change onto all room versions per MSC4291 The MSC asks the `description` of `auth_events` to be adjusted, however this feels like a better representation of the change. Add `room_id` format rules and renumber per MSC4291 Reflect change to rule 1.2 per MSC4291 Insert same room_id check to v1-12 auth rules per MSC4307 and MSC4291 Deprecate `predecessor.event_id` per MSC4291 Insert auth rule to validate `additional_creators` per MSC4289 Insert rule for `users` validation of creators and renumber per MSC4289 Define "room creator(s)" per MSC4289 Spec `additional_creators` on create events per MSC4289 Spec `additional_creators` on `/upgrade` per MSC4289 The MSC doesn't mention how to handle unsupported room versions, but the Synapse implementation used for FCP ignores the field in such room versions. This feels like a good approach, and will need clarifying in the MSC too (if accepted at the spec level). Add notes to `/upgrade` behaviour per MSC4289 and MSC4291 Describe how additional creators work during room creation per MSC4289 Fix default user power level descriptions per MSC4289 Describe tombstone power level changes per MSC4289 Warn clients about event format changes in v12 per MSC4289 and MSC4291 Flag additional room creators support for client reference per MSC4289 Remove TODO now that it's fully addressed Copy state res into v12 as-is for modification Apply Modification 1 to SR2.1 per MSC4297 Apply Modification 2 to SR2.1 per MSC4297 Add summary box to the top of SR2.1 for ease of developer reference Modification 2 was split into items 2 and 3 for further ease of understanding. Add all the changelogs `x` is used until a real PR number can be assigned. Some changelogs are duplicated to the Client-Server API to increase visibility of the changes to v12. Review: Minor phrasing adjustments in changelogs Review: Clarify that v12 isn't quite the default yet in the changelog Review: Clarify to clients that creators are immutable Review: Improve 'how to parse a domain' advice for legacy apps Review: Add a bit more detail as to why a room ID might be required Apply suggestions from code review Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> Clarify that clients can override the tombstone default Mention creatorship UI label by finishing the Permissions section We probably should have removed the WIP note in v1.0, but alas. Add changelog for tombstone changes Use assigned spec PR number in changelogs (cherry picked from commit ec81eea7e4532fd398b8013071d6981c97117d9e)
84 lines
3.2 KiB
Markdown
84 lines
3.2 KiB
Markdown
|
|
### 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
|
|
|
|
{{% event event="m.room.tombstone" %}}
|
|
|
|
#### 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.
|
|
|
|
{{% http-api spec="client-server" api="room_upgrades" %}}
|
|
|
|
#### 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 v="1.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.
|
|
|
|
{{% boxes/note %}}
|
|
{{% added-in v="1.16" %}} If both the new and old [room version](/rooms) support
|
|
additional creators, the server will not transfer those additional creators automatically.
|
|
They must be explicitly set during the `/upgrade` call.
|
|
{{% /boxes/note %}}
|
|
|
|
{{% boxes/note %}}
|
|
{{% added-in v="1.16" %}} When upgrading to room version 12 or later, the `predecessor` field MAY NOT contain
|
|
an `event_id`.
|
|
{{% /boxes/note %}}
|
|
|
|
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.
|