You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec-proposals/proposals/4121-m.role.moderator.md

2.9 KiB

MSC4121: m.role.moderator /.well-known/matrix/support role.

Introduction

The current supported roles for the support record of m.role.admin and m.role.security leave one primary flaw open. What if homeserver administration is completely disjointed from homeserver moderation?

This case is currently not supported under this scheme as the only non wildcard role is security. Its not hard to imagine that if your a managed hosting provider for a matrix homeserver that your the listed contact for matters like your server is outdated or my server is having federation issues with your server.

But you are not the right party to contact for problematic users. That's the homeserver moderation teams area. So this proposal aims to solve this via adding m.role.moderator as the third supported role.

Proposal

This proposal is quite simple as all it does is introduce m.role.moderator as a valid option for the role under /.well-known/matrix/support.

As is mentioned in the introduction to the proposal this helps cases where homeserver administration and moderation are disjointed. This setup exists out in the wild on the community side where a trusted community member acts as homeserver admin for a server but is not part of that servers moderation team.

This makes sense as the skill of community manager often does not overlap with those of a great systems administrator. And by separating these roles the systems administrator does not need to forward as many reports that found them self's in the wrong pile.

If a server only has m.role.admin defined then the administrator is either a catch-all or forwards requests internally. But if m.role.admin and m.role.moderator are defined then moderation matters are to be directed towards m.role.moderator and administration matters towards m.role.admin.

Potential issues

This Proposal shouldn't have that many potential issues other than that it gives more opportunities for end user confusion but so do all choices.

Alternatives

There aren't that many good alternatives to this if any within the framework of the support record that the author can identify. And why this is the correct choice the author feels has been thoroughly gone through.

Security considerations

This Proposal shouldn't have security related impacts unless we account for the impacts of users potentially sending reports to the wrong bucket but that concern is already there with the current security and administration split.

Unstable prefix

While this proposal is not yet accepted into the specification one should use support.feline.msc4121.role.moderator in place of m.role.moderator

Dependencies

This MSC does not depend on any MSCs that have not been accepted into the specification. This MSC builds on the systems introduced in MSC1929 that is part of the 1.10 spec release.