Skip to content

MSC4489: Per-room contact state event#4489

Open
ll-SKY-ll wants to merge 3 commits into
matrix-org:mainfrom
ll-SKY-ll:ll-SKY-ll-patch-1
Open

MSC4489: Per-room contact state event#4489
ll-SKY-ll wants to merge 3 commits into
matrix-org:mainfrom
ll-SKY-ll:ll-SKY-ll-patch-1

Conversation

@ll-SKY-ll
Copy link
Copy Markdown

@ll-SKY-ll ll-SKY-ll commented Jun 5, 2026

Signed-off-by: Sky [email protected]

rendered

@turt2live turt2live changed the title per-room contact state event MSC4489: Per-room contact state event Jun 5, 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.

Implementation requirements:

  • Client (setting)
  • Client (reading/using)

@turt2live turt2live added proposal A matrix spec change proposal. Process state. A-Client Server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Jun 5, 2026
Copy link
Copy Markdown
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

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

Early partial review of MSC

Comment thread proposals/4489-per-room_contact_state_event.md Outdated
state event — which is independently useful to existing members and to bots
that are in the room — is not blocked on federation/client changes.

## Alternatives
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.

Specifically for appeals, the Reporting v2 thought is currently #4468 fwiw

`""` as its state key; a room has at most one such event. It is ordinary room
state and requires no new room version.

Its `content` reuses the `contacts` and `support_page` fields, with the same
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

As a room admin, I would be worried about these values becoming stale and needing to roll out new values to all of my rooms whenever these change. I wonder about the potential merits of a "support_via": "matrix.org" field that would "redirect" users to the /.well-known/matrix/support of a given server name?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

i dont understand the issue. In that case you might wish to just populate the support_page and nothing else

{
"matrix_id": "@alice:example.org",
"email_address": "[email protected]",
"role": "m.role.security"
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

What would a security contact on a room actually be responsible for?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

The examples were made based on the currently available options in the m.role.* namespace, they don't necessarily all have a real world use case today, though that doesnt mean there wont be someone finding a use for it eventually. This proposal also hopes to inspire new proposals to expand the options available to the m.role.* namespace like MSC4121 already does.

@ll-SKY-ll ll-SKY-ll marked this pull request as ready for review June 7, 2026 09:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Client Server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal. Process state.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants