matrix-spec-proposals/proposals/4289-privilege-creators.md

MSC4289: Explicitly privilege room creators

NOTE: This MSC is part of the security update to Matrix announced at https://matrix.org/blog/2025/07/security-predisclosure/. This is a lightly edited version of the final MSC, released ahead of the disclosure in order to aid client implementors with implementation, and will be updated with full security context upon disclosure.

Problem

Matrix has a longstanding problem that creators can lose control of rooms, either by promoting other admins who they can then no longer demote or by demoting themselves (https://github.com/matrix-org/matrix-spec/issues/165). Despite warnings from clients about these limitations, it is still surprising to users.

This MSC gives the room creator(s) an ability to demote those admins (or promote themselves).

This MSC also addresses other forthcoming security considerations.

Proposal

In short:

• Formally define the ‘room creator’ as the user who sent the m.room.create event for a given room. By definition, this is immutable per room.
• Update auth rules so that the ‘room creator’ and additional_creators (see below) are always considered to have infinite power level. This means when sorting this user by PL, they always sort last ascending and first descending. Users with MAX_INT power level are still less than creators.
• Clients may guide creators who try to demote themselves to get someone else to upgrade the room instead.
• Clients no longer need to warn creators that if they promote someone to admin they won’t be able to undo it. They may need to highlight that any additional creators cannot be removed.
• Given the changes to auth rules need to be executed consistently across all servers, this requires a new room version.

It is important to note that this does NOT centralise the room on the creator’s server. The room remains fully functional if the creator’s server is unreachable, as nothing in the protocol requires communicating exclusively with the creator’s server. Indeed, the room remains fully functional in the face of arbitrary network partitions. Conversation history is still replicated equally over all participating servers, and the access control hierarchy can be shared equally across multiple servers, and is enforced independently by all participating servers. However, access control, by definition, specifies how some users are privileged over other users in a given context - and in such a hierarchy, some entity always ends up on top.

This fixes Should room creators always be able to give themselves power? once and for all (previous attempts being MSC3915 “owner power level” and MSC3510 “let the same PL kick/ban/deop each other”).

[!NOTE] Clients which show a user's power level SHOULD indicate ‘creatorship’ in a similar way to help manage expectations on access control to users (i.e. to remind users who created the room, and so who can override access controls).

Create event changes

To support fully multilateral decentralisation, the create event content MAY include a new field additional_creators which is a list of user IDs. All the user IDs specified have the same permissions as the original creator. The auth rules are updated to include additional validation on the create event:

• If type is m.room.create:
  • 3: [...]
  • 4: Otherwise, allow.
  • 4: NEW: If the additional_creators field is present and is not an array of strings where each string passes the same user ID validation that is applied to the sender, reject.
  • 5: Otherwise, allow.

User IDs in additional_creators are NOT bound to the creator server: any valid user ID may be provided.

Earlier versions of this proposal explicitly stated that additional_creators must be a valid user ID but due to ambiguity between allowed/historical/invalid user IDs that exist on the public network, this proposal merely states that the same validation applied on the sender key should be applied on the additional_creators field. If this proposal is too strict, it would prevent historical user IDs from joining rooms with this MSC. The intention of this wording is to allow the validation to be changed as and when the validation of the sender key changes. See MSC2828 and this clarification for more information.

This new field is especially useful when creating DMs, as both parties retain equal control of the room.

/createRoom changes

In order to ensure Direct Message rooms have both the creator and recipient as joint creators, /createRoom requests with BOTH preset: trusted_private_chat and users in the invite field have additional meaning server-side. The server SHOULD copy any users in the invite field into the creation_content.additional_creators field in the request body and de-duplicate them. The net result is that the union of invite and creation_content.additional_creators in the request body form the additional_creators in the m.room.create event.

Power levels event changes

This change affects the m.room.power_levels event which will no longer have the creator user ID with 100 by default. Instead, the users map will be empty, and clients/servers must infer that the creator has infinite power level based on the m.room.create event's sender (and content.additional_creators if present).

The auth rules for m.room.power_levels events are adjusted to say:

9. If type is m.room.power_levels:

• 1). If any of the properties users_default, events_default, state_default, ban, redact, kick, or invite in content are present and not an integer, reject.
• 2). If either of the properties events or notifications in content are present and not an object with values that are integers, reject.
• 3). If the users property in content is not an object with keys that are valid user IDs with values that are integers, reject.
• 4). NEW: If the users property in content contains the sender of the m.room.create event or any of the user IDs in the create event's additional_creators array within content, reject.
• 5). ...rest of rules...

This ensures that there can be no confusion among clients or servers if the creator were to have a PL entry in the users map.

[!NOTE] We could add a compatibility shim which would inject the creators into the PL event for clients. Naively, this would set the creators to be max(users)+1. This naive solution is wrong though, as some PL events may have "the level required to send event X" to be higher than any other user, so the shim would also need to be max(PL_to_send_anything)+1 in addition to max(users)+1.

However, this would introduce new problems for client implementations:

• This shim would break any client which asserts MAX_INT in power levels, as the creator PL would have to be 1 greater than the actual max a real user could have.
• Creators would appear to break PL transition rules, as they would be seen to give themselves more power (e.g if the max PL of non-creators was 100, then they increased a non-creator to 150, the same event would also transition all creators to PL151). This would also be confusing to render, as there would appear to be two changes (creator->PL151 and target user->PL150), when it practice only one change was made.
• This logic makes it harder to transition to pure P2P systems in the future, where clients sign federation events, as clients would have to assert that the PL transitions are valid before committing a signature to authorise it.
• The lack of any new role descriptor (e.g "Creator") means in practice major clients would simply list the creators as "Admin" (any PL>=100). This could cause confusion among users if a creator were to demote an admin, as this should not be possible.

This change does not add significantly more complexity to the calculation of PLs for users in a room because both clients and servers have always needed BOTH the m.room.power_levels and m.room.create events in order to display PLs correctly (as in previous room versions the absence of a PL event means the creator has PL100). For this reason and the ones listed above, no compatibility shim is proposed with this proposal.

Tombstone changes

The initial power levels event in the room MUST have the level required to send m.room.tombstone events be higher than the level required to send state events. This is to ensure only creators are able to upgrade the room by default, but allowing them to transfer ownership by increasing the PL of any user to PL150 (for example) to allow them to send the tombstone event. Note: this may still be overridden by power_level_content_override.

The rationale for this is as follows: Matrix does not allow users with the same PL to demote each other. Upgrading a room breaks this because the non-creator doing the upgrade will now gain unlimited PL, potentially demoting the original creator ("potentially" because they could be set via additional_creators during the upgrade process). As such, more protections need to be in place to guard against unauthorised privilege escalation by admins, hence the introduced of a new PL150 tier for tombstoning the room. If we kept the ability to tombstone to be PL100, then by default it would be impossible to allow someone to A) change the server ACLs, B) update history visibility, without also C) giving them the ability to privilege escalate.

Room upgrades

A new additional_creators key is added to the /upgrade endpoint. This has the same validation rules applied as the additional_creators field in the m.room.create event, and serves as a way to transfer ownership of a room (remove a creator). This key behaves in the same way as if it were specified in the creation_content in /createRoom: the entire set of additional creators are specified up-front. For example, consider the following scenario:

• Alice created a room and put Bob as an additional creator.
• Charlie has PL150 and wants to upgrade the room so Alice is no longer a creator. He wants to keep Bob as an additional creator.
• Charlie can /upgrade the room and specify Bob as an additional creator.
• The new room does not have Alice as a creator or additional creator.

This allows the creator status to move between users.

Potential Issues

Any update to the set of creators in a room requires a room upgrade. This means room upgrades will occur more often than today. Forming a complete timeline history across several rooms may make a number of things harder for implementations. For instance, it increases the pressure to implement seamless merging of timelines across a tombstone rather than the currently widespread "click to jump to the old room" UX.

Clients which don't already implement the default power level for creators may experience bugs where users who just created a room cannot (visually) change details of that room, such as adding admins or setting the room's topic. A server-side backwards-compatibility shim to append the room creators to the power levels event over the Client-Server API as 2**53-1 (JavaScript's Number.MAX_SAFE_INTEGER) was considered, however with the expectation that most communities will upgrade their rooms when they're ready rather than immediately upon availability of this MSC, clients in particular will have opportunity to be updated accordingly.

Similarly, clients which attempt to set an explicit PL for the creator(s) will fail. A backwards-compatibility shim was considered to ignore PLs set for creator(s) but rejected, on the basis of causing avoidable confusion and technical debt, given clients are already making breaking changes for this room version.

Alternatives

(Embargoed until Aug 14, 2025)

Security Considerations

(Embargoed until Aug 14, 2025)

Credits

Thanks to Timo Kösters for initiating discussion around this MSC.

Unstable prefix

During development this room version is referred to as org.matrix.hydra.11 alongside MSC4291 and MSC4297 (embargoed until Aug 14, 2025).

Dependencies

This MSC depends on "MSC4291: Room IDs as hashes of the create event".