matrix-org / matrix-org/matrix-spec
Handling of m.mentions and notifications.room in m.room.power_levels not explicit
- 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
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