matrix-org / matrix-org/matrix-spec

Handling of m.mentions and notifications.room in m.room.power_levels not explicit

Open Beginner friendly
#2,443 2 comments 1 reaction 0 assignees View on GitHub
clarification
Dominant language
HTML
Stars
330
Forks
150
Avg merge
2h 21m
Merged PRs (30d)
3

Description

**Link to problem area**:

- [User and room mentions](https://spec.matrix.org/v1.19/client-server-api/#user-and-room-mentions)
- [`m.room.power_levels`](https://spec.matrix.org/v1.19/client-server-api/#mroompower_levels)
- [Authorisation rules](https://spec.matrix.org/v1.19/rooms/v12/#authorisation-rules) (room version 12)

**Issue**

Raised by @gewitternacht in https://github.com/matrix-org/matrix-spec-proposals/pull/4075#discussion_r3989550458. The spec currently doesn't make it very clear how the `room` setting in `m.room.power_levels` is enforced. The only related reference is this warning:

> If an encrypted event contains an `m.mentions` in its payload, it should be encrypted as normal. To properly process mentions in encrypted rooms, events must be decrypted first. See [receiving notifications](https://spec.matrix.org/v1.19/client-server-api/#receiving-notifications).

As far as I understand, due to encryption, the server doesn't check mentions when it checks power levels in step in step 8 of the authorisation rules. That means the `room` power level is only checked by receiving clients via their push rules. In other words, events with room mentions are allowed by servers even if the sender doesn't have the room power level but receivers don't allow it to trigger notifications.

I think it would help if this were spelled out in the spec.

Contributor guide

Open the contributing guide

Research direction

Start by reading the linked User and room mentions, m.room.power_levels, and room version 12 authorisation rules sections, then compare them with the receiving notifications guidance. Update the specification so it explicitly states how encrypted room mentions and the room power level are handled; the relevant behavior should be unambiguous to servers and receiving clients.

Written by the indexing model from the issue text.

Assessment

Domain
backend-api-design, documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
70/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.