Unlike account locking, suspension allows the user to have a (largely) readonly view of their account. Homeserver administrators and moderators may use this functionality to temporarily deactivate an account, or place conditions on the account's experience. Critically, like locking, account suspension is reversible, unlike the deactivation mechanism currently available in Matrix - a destructive, irreversible, action.
This proposal introduces an error code for communicating suspension to a user, alongside some guidelines for how suspension could be implemented by a server. APIs to invoke or clear suspension are not introduced, and left as an implementation detail. These will typically be done through an administrator-only API.
When an account is suspended, any Client-Server API
endpoint MAY return a 403 HTTP status code with errcode
of M_USER_SUSPENDED
. This indicates to
the user that the associated action is unavailable.
Clients should note that for more general endpoints, like /send/:eventType
, suspension MAY only be
applied to a subset of request parameters. For example, a user may be allowed to redact events but
not send messages.
The specific list of permitted actions during suspension is left as a deliberate implementation detail, however a server SHOULD permit the user to:
- Log in/create additional sessions (which should also behave as suspended).
- See and receive messages, particularly via
/sync
and/messages
. - Verify their other devices and write associated cross-signing data.
- Populate their key backup.
- Leave rooms & reject invites.
- Redact events.
- Log out/delete any device of theirs, including the current session.
- Deactivate their account, potentially with a deliberate time delay to discourage making a new account right away.
- Change or add admin contacts, but not remove.
The suggested set of explicitly forbidden actions is:
- Joining or knocking on rooms, including accepting invites.
- Sending messages.
- Sending invites.
- Changing profile data (display name and avatar).
This proposal does not communicate why a user's account is restricted. The human-readable error
field may contain some information, though anything comprehensive may not be surfaced to the user.
A future MSC is expected to build a system for both informing the user of the action taken against
their account and allow the user to appeal that action.
No significant alternatives are plausible. M_USER_DEACTIVATED
could be expanded with a permanent
flag, though ideally each error code should provide meaning on its own.
The related concept of locking, as discussed in places like MSC3939 and matrix-org/glossary, is semantically different from suspension.
Until this proposal is considered stable, implementations must use
ORG.MATRIX.MSC3823.USER_SUSPENDED
instead of M_USER_SUSPENDED
.