Skip to content

MSC4106: Join as Muted #4106

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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

MSC4106: Join as Muted #4106

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0ae3b2e
Initial Commit
FSG-Cat Feb 17, 2024
e00b092
Update MSC to feature MSC number.
FSG-Cat Feb 19, 2024
1811fe2
Clarify introduction and link to referenced MSCs.
FSG-Cat Feb 22, 2024
11500c4
Addres why Knocking is not always an alternative
FSG-Cat Feb 26, 2024
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
76 changes: 76 additions & 0 deletions proposals/4106-join-as-muted.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
# MSC4106: Join as Muted

## Introduction

Currently in matrix we lack the ability to implement proper membership screening mechanisms. This is
due to that we cant use PL based screening as it has all the problems that MSC3909 and MSC3907 covers.

This proposal aims to by extending MSC3909 solve this problem as membership screening is a function that
is desired by some end users. Stakeholders like The Draupnir Project that the Author does participate
in can not proceed to solve these end user concerns in a satisfactory manner without mechanisms like
those that this proposal enable.

This Proposal resolves this problem by introducing a mechanism where all join rules flip from transitioning
membership to `join` from a previous state like `leave`,`invite`,`knock` or not having a membership at all to `mute`.

The idea with this being that if you join a room as muted you cant interact in a race condition way where
you get to fire of spam before automatic tooling mutes you pending membership screening.


## Proposal

A room that uses Join as muted operating mode will put a `default_membership` key in its `m.room.join_rules`
this key can only for now contain either `join` or `mute` as its state to indicate normal or altered operating
mode. If this is missing from the event normal behaviour is assumed.

When `default_membership` equals `mute` trying to will instead of setting your membership to `join` will set it
to `mute` with a special consideration being that if you do not have a previous membership event, you are allowed
to set profile information. This is to make it so you have valid profile information for your initial join as muted
members are not allowed to update profile information usually to avoid an attack vector.

To be written. Proper list of all the transitions in detail.

### Authorisation rules.

To be written. Contributions welcome. (Please note that this MSC builds on MSC3909)

## Potential issues

This MSC comes with the disadvantage of even further complicating membership transitions than they are already.
The author dismisses this concern due to that this is the only viable to the author way of implementing this feature.

## Alternatives

All existing RBAC MSCs at the time of writing that the author is aware of have been dismissed due to them
all sharing the flaw of that you cant Access Control a unbounded amount of members like membership based
access controls can do. And as for the why not just mute them on join issue that is described earlier.

Also the alternative of making `default_membership` be a different but Boolean key was not picked as to
enable this mechanism to be extended in the future without causing client side stakeholders to be confused.
This design choice encourages being adaptable to that this can change in the future and therefore avoiding
a v11 situation. (Room version 11 caused Element iOS to crash when trying to open a v11 room.)

A separate state event was dismissed due to that it makes the most sense to put this in the join rules to the author.
This is a weak alternatives case the author does recognise and is therefore left open as a possible alternative for now.

Copy link

Choose a reason for hiding this comment

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

Other things that currently exist:

  • Setting the default power level. Currently the closest thing to join as muted, but it causes issues with the power level state event when lots of users are unmuted.
  • knock join rule: This exists for the use case of screening people before they join.

Between setting default power levels for "most users will stay muted" and knock for "most users will be unmuted", I'm not sure what the purpose of this msc is? It does combine the two use cases together but would end up adding a third way to implement default mutes a la xkcd: standards. My two best guesses are that knock implies that most people will become unmuted while mute makes no such implication, and mute could allow previewing the room (...though, having a history_visibility rule to allow invite/knock users to join would be nice). What else could mute do that knocking doesn't?

Copy link
Contributor Author

@FSG-Cat FSG-Cat Feb 26, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Default powerlevels are adressed as completely and utterly unsuited for this usecase the prior art of MSC3909 can explain it a bit more. But lets summarise that Powelevels are ridicoulously expensive state res wise compared to memberships in my understanding and also have the even bigger achiles heel of limited user count that can be affected as a fundemental and unfixable flaw under current models. (Multiple events have been dismissed wholesale for now)

Knock is intresting but it has the flaw of that you cant join the room in the sense that you have to solve Peeking over federation to make Knocking a viable alternative in my opinion as you might want to see if the room is for you for example before trying to pass membership screening.

So Knock will have to be dismissed as an alternative as its a true flaw of the MSC that its not addressed. Powerlevels are tho dismissed wholesale properly i thought but i might need to do a second pass.

Edit: Removed section about Rotation of Join rules because i realised no you dont actually have to touch in room state as the automatic screening proces is identical for this proposal and knock in that regard.

Copy link

Choose a reason for hiding this comment

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

This begs the question why have a separate default-mute join rule type rather than improve peeking over federation - it looks like it'll be implemented anyways and will obsolete this msc?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tbh i would be happy to have this be redundant if that materialised and was found to be viable.

## Security considerations

Alternatives section does go into Security Considerations a bit and so does this proposals Relatives in MSC3909 and MSC3907
when it comes to mutes so lets dig into what this MSC does for security. It should do relatively little to worsen
security as all it does is make it so someone who joins the room is muted instead and therefore blocking the
attack vector of racing with the automatic tool that mutes you to enable membership screening. Membership screening
being the flagship usecase for this specific MSC.

Now yes this MSC does worsen security by adding even more complexity to the already very complex membership state machinery
enabling more ways of screwing that up.

## Unstable prefix

This MSC is not recommended to be implemented before Authorisation rules are properly specified but if implemented. Please use the version string of `support.feline.mute.msc3909+msc4106.v0`

Once Authorisation rules are specified it's expected that the unstable version after that is v1. This is because the pre authorisation rules properly written down version cant be trusted to interoperate and this is why its NOT recommended to implement a version that is based on this MSC before that section is written.

## Dependencies

This MSC builds on MSC3909 as a direct dependency on it (which at the time of writing have not yet been accepted
into the spec).