matrix-spec/data/event-schemas/schema/m.room.power_levels.yaml

130 lines
5.7 KiB
YAML
Raw Normal View History

---
$schema: https://json-schema.org/draft/2020-12/schema
allOf:
- $ref: core-event-schema/state_event.yaml
description: |-
This event specifies the minimum level a user must have in order to perform a
certain action. It also specifies the levels of each user in the room.
If a `user_id` is in the `users` list, then that `user_id` has the
associated power level. Otherwise they have the default level
`users_default`. If `users_default` is not supplied, it is assumed to be
0. If the room contains no `m.room.power_levels` event, the room's creator has
a power level of 100, and all other users have a power level of 0.
The level required to send a certain event is governed by `events`,
`state_default` and `events_default`. If an event type is specified in
`events`, then the user must have at least the level specified in order to
send that event. If the event type is not supplied, it defaults to
`events_default` for Message Events and `state_default` for State
Events.
If there is no `state_default` in the `m.room.power_levels` event, or
there is no `m.room.power_levels` event, the `state_default` is 50.
If there is no `events_default` in the `m.room.power_levels` event,
or there is no `m.room.power_levels` event, the `events_default` is 0.
The power level required to invite a user to the room, kick a user from the
room, ban a user from the room, or redact an event sent by another user, is
defined by `invite`, `kick`, `ban`, and `redact`, respectively. The levels
for `kick`, `ban` and `redact` default to 50 if they are not specified in the
`m.room.power_levels` event, or if the room contains no `m.room.power_levels`
event. `invite` defaults to 0 in either case.
**Note:**
The allowed range for power level values is `[-(2**53)+1, (2**53)-1]`,
as required by the [Canonical JSON specification](/appendices/#canonical-json).
properties:
content:
properties:
ban:
description: The level required to ban a user. Defaults to 50 if unspecified.
2018-08-28 02:59:35 +02:00
type: integer
events:
additionalProperties:
2018-08-28 02:59:35 +02:00
type: integer
Room version 12 (#2193) * 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)
2025-08-14 19:16:00 +02:00
description: |-
The level required to send specific event types. This is a mapping from event type to power level required.
Though not a default, when the server sends the initial power levels event during [room creation](/client-server-api#creation)
in [room versions](/rooms) 12 and higher, the `m.room.tombstone` event MUST be explicitly defined and given
a power level higher than `state_default`. For example, power level 150. Clients may override this using the
described `power_level_content_override` field.
x-changedInMatrixVersion:
"1.16": Described `m.room.tombstone` defaults during creation of a room version 12 or higher room.
title: Event power levels
type: object
events_default:
description: |-
The default level required to send message events. Can be
overridden by the `events` key. Defaults to 0 if unspecified.
2018-08-28 02:59:35 +02:00
type: integer
invite:
description: The level required to invite a user. Defaults to 0 if unspecified.
2018-08-28 02:59:35 +02:00
type: integer
kick:
description: The level required to kick a user. Defaults to 50 if unspecified.
2018-08-28 02:59:35 +02:00
type: integer
redact:
description: The level required to redact an event sent by another user. Defaults to 50 if unspecified.
2018-08-28 02:59:35 +02:00
type: integer
state_default:
description: |-
The default level required to send state events. Can be overridden
by the `events` key. Defaults to 50 if unspecified.
2018-08-28 02:59:35 +02:00
type: integer
users:
patternProperties:
"^@":
x-pattern-format: mx-user-id
type: integer
Room version 12 (#2193) * 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)
2025-08-14 19:16:00 +02:00
description: |-
The power levels for specific users. This is a mapping from `user_id` to power level for that user.
**Note**: In [room versions](/rooms) 12 and higher it is not permitted to specify the room creators here.
x-changedInMatrixVersion:
"1.16": Added a note that room creators cannot be specified here in room versions 12 and higher.
title: User power levels
type: object
users_default:
Room version 12 (#2193) * 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)
2025-08-14 19:16:00 +02:00
x-changedInMatrixVersion:
"1.16": The room creator power level now changes depending on room version.
description: |-
The power level for users in the room whose `user_id` is not mentioned in the `users` key. Defaults to 0 if
unspecified.
Room version 12 (#2193) * 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)
2025-08-14 19:16:00 +02:00
**Note**: In [room versions](/rooms) 1 through 11, when there is no `m.room.power_levels`
event in the room, the room creator has a power level of 100, and all other users have a
power level of 0.
**Note**: In room versions 12 and higher, room creators have infinite power level regardless
of the existence of `m.room.power_levels` in the room. When `m.room.power_levels` is not
in the room however, all other users have a power level of 0.
2018-08-28 02:59:35 +02:00
type: integer
notifications:
2018-04-15 23:41:24 +02:00
properties:
room:
2018-08-29 22:18:41 +02:00
type: integer
description: The level required to trigger an `@room` notification. Defaults to 50 if unspecified.
additionalProperties:
2018-08-29 22:18:41 +02:00
type: integer
description: |-
The power level requirements for specific notification types.
This is a mapping from `key` to power level for that notifications key.
2018-04-15 23:41:24 +02:00
title: Notifications
type: object
type: object
state_key:
description: A zero-length string.
pattern: '^$'
type: string
type:
enum:
- m.room.power_levels
type: string
title: Defines the power levels (privileges) of users in the room.
type: object