Skip to content

MSC3784: Using room type of m.policy for policy rooms #3784

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
turt2live merged 9 commits into from
Jul 13, 2026
Merged

MSC3784: Using room type of m.policy for policy rooms #3784

Changes from 8 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
3a39930
Add files via upload
FSG-Cat Apr 25, 2022
32dca9f
Rename MSCXXXX Using room type of m.policy for policy rooms.md to XXX…
FSG-Cat Apr 25, 2022
4e5c46c
Rename XXXX-Using-room-type-of-m.policy-for-policy-rooms.md to XXXX-u…
FSG-Cat Apr 25, 2022
8f3a8b4
Update and rename XXXX-using-room-type-of-m.policy-for-policy-rooms.m…
FSG-Cat Apr 25, 2022
8d99dca
Improve Post merge information
FSG-Cat Jul 24, 2022
7278e35
Apply suggestions made by Travis R.
FSG-Cat Mar 20, 2026
5b6fb95
Fix markdown linting issues.
FSG-Cat Apr 21, 2026
49a15d9
Integrate review feedback from Gnuxie
FSG-Cat Apr 21, 2026
171c424
Reword Unstable section to be more readable.
FSG-Cat Jun 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# MSC3784 Using room type of m.policy for policy rooms
Comment thread
turt2live marked this conversation as resolved.

@FSG-Cat FSG-Cat Nov 27, 2022 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making this thread to track Implementation status outside of the PR descript.

Implementation Tracking

Mjolnir as of da08432 and that commit is included in Release 1.6.0. Mjolnir implementation at time of writing only includes that it creates rooms for policy lists with the type.
Nheko in mtxclient has added initial support to recognise it in 4bd39bce. Further progres unknown at time of writing.

@clokep clokep Jun 13, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Nheko use it besides just declaring the constant?

@FSG-Cat FSG-Cat Oct 11, 2024

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Policy Editing that utilises MSC3784 to aid in detecting if a room is a policy list is implemented in RMU. Version that implemented first is unknown but current Version as of writing relies on this as one of its 2 detection methods. It also supports legacy detection.

@TheArcaneBrony TheArcaneBrony Mar 20, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://mru.rory.gay/PolicyLists is the particular page in RMU that uses this MSC to find policy rooms. I'm not sure whether it has legacy detection enabled or not, but legacy detection here was implemented by checking for the Mjolnir shortcode state event. It does not show rooms that happen to have policy events, as querying /sync or /state for rooms is very expensive, especially compared to cherry picking 2 events.

(Oops, I still have to get rid of the "Create policy list" popup being there by default, which also uses the MSC's unstable type on room creation, additionally I've just uncovered a crash related to fetching room names... That's for the tomorrow pile).


## Introduction

Matrix already has [Moderation Policy Lists](https://spec.matrix.org/v1.17/client-server-api/#moderation-policy-lists)
which describe policy recommendations through state events. In typical usage,
these policy recommendations tend to appear in dedicated rooms, though are not
required to.

Having the policy recommendations in dedicated rooms helps clients better understand
the purpose of a room, and potentially hide it if the client knows it can't do
much with that dedicated purpose. For example, a messaging client might want to
hide policy list rooms by default to avoid showing "non-conversational" rooms to
the user.

This proposal introduces a [room type](https://spec.matrix.org/v1.17/client-server-api/#types)
to denote such dedicated rooms.

## Proposal

Rooms dedicated to containing policy list recommendations SHOULD use a newly
defined `m.policy` room type. How clients choose to (not) handle the new type is
left as an implementation detail.

Where the `m.policy` room type is used, conversation is not expected.

@clokep clokep Apr 21, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small quibble that I wouldn't block this MSC on, but should we use m.moderation_policy to be a bit more descriptive? I could think of multiple types of policies.

@TheArcaneBrony TheArcaneBrony Apr 22, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the policy server MSC then also be updated to use m.moderation_policy as an event type rather than m.policy or whatever the final variant was?

@FSG-Cat FSG-Cat Apr 23, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not married to any particular final name for the room type. I was just copying the precedent set by spaces at the time of writing originally.

So i will take this to the saftey guild and ask them for input on what the name should be.

@clokep clokep Apr 23, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we're already using this term, and that's ok. Thanks for providing the context on why this was chosen. It just stuck out to me as really vague.

Would be curious for other SCT input here.

@richvdh richvdh Jun 2, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like @turt2live would have more context on whether this is a sensible name or not. I agree that m.policy feels a bit vague.

@turt2live turt2live Jun 2, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the person who advocated for m.room.policy to enter the spec as-is, I'm not sure my opinion is super reliable 😅. I'm personally fine with m.policy as a room type because it's "a room containing a policy". The 'policy' happens to be expressed with primarily ban rules, but in future could be more than that (anonymous reputation data, shades of gray policy definitions to determine on-topic-ness, etc).

I'm also generally of the opinion that calling it a "moderation policy list" in the spec is wrong, but I'm not concerned enough to actually raise a bug fix PR or issue for it. The use case is to communicate general policy data, not specific to moderation. This could be a security policy, entrance policy, community volunteer policy, etc.

@FSG-Cat FSG-Cat Jun 2, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A practical use case that exists today where policies are not "moderation policies" would actually be the Access controls for Mjolnir and Draupnir Appservice mode. While they are broken in Draupnir currently they work in Mjolnir as far as i know because it used to work in Draupnir and we did not touch that part of the codebase to my knowledge in that way. (I should note we use the moderation policy recommendations in this context but thats also more of a easiest path forward type of situation i would argue. But thats also only for the disallow policy the allow policy is a custom one in the org.matrix namespace.)

In this case the policies simply control if your bot is allowed to start or not and if your doing Appservice hosting as a service you can easily hook this into a subscription management system. Be that paid or free subscriptions.

Point im trying to make is that we have a concrete already in the wild use case where policies are not strict moderation but something a bit different and we have lots of exploration wanting to extend this system further.

Personally i would say that room sub typing also comes into play here as if we had sub typing then definitively could argue if moderation should be its own subtype and the flagship subtype for the first MSC to try to define a policy subtype due to its clear and proven track record.

Now the fact that the appservice admin room is where Mjolnir and Draupnir stores the policy list is a design choice that as far as i understand exists out of convenience not any actual necessity. Appservice mode was a small beta project that had beta issues that make complete sense in context. The admin room having the policies is one of them and is a choice that i personally would argue for moving away from if one wants to modernize the mode (and is something i may personally look at in the future inside of the Draupnir project) as the room type benefits are quite large for specialized tools like RMU and any other matrix client that wants to implement policy manipulation.

Clients SHOULD note that moderation policies can appear in rooms without the `m.policy` type,
where conversation could be present.

## Potential issues

Clients which have dedicated UX for policy rooms might not be able to apply that
UX to rooms missing the `m.policy` room type. They can try to look for recommendation
state events contained in the room, though if their dedicated UX is invasive then
it may hide conversation being had in the room. This proposal does not attempt to
make rooms without the `m.policy` room type, but still contain policy recommendations,
invoke any dedicated UX a client might have - clients can choose how/if they handle
this case.

## Alternatives

Peeking over federation, like in [MSC2444](https://github.com/matrix-org/matrix-spec-proposals/pull/2444),
can help clients identify rooms which contain policy list recommendation state
events. However, as identified above, this may be insufficient to properly
identify rooms *dedicated* to containing those state events.

## Security considerations

This change is largely informative and carries no direct security impact. Clients
which interpret the `m.policy` room type will need to consider security in their
implementations. For example, if hiding the rooms then notifications in those
rooms will need some consideration.

## Unstable prefix

If you want to implement this MSC before its merged you're free to use the unstable type of
`support.feline.policy.lists.msc.v1`.

After this MSC gets merged if a stakeholder has elected to remove its support for the unstable prefix if any
Because the room type is immutable, rooms which use the unstable room type might
find themselves "unsupported" when/if implementations drop support for the unstable
type when this proposal becomes stable.
Comment thread
richvdh marked this conversation as resolved.
Outdated

## Dependencies

The Author is not aware of any unstable MSC dependencies for this MSC.
Loading