Skip to content
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.

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

MSC4106: Join as Muted #4106

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

Conversation

FSG-Cat
Copy link
Contributor

@FSG-Cat FSG-Cat commented Feb 19, 2024

Rendered

This MSC enhances membership screening capabilities.

Signed-off-by: Catalan Lover [email protected]

@FSG-Cat FSG-Cat changed the title MSCXXXX Join as Muted MSC4106 Join as Muted Feb 19, 2024
@FSG-Cat FSG-Cat changed the title MSC4106 Join as Muted MSC4106: Join as Muted Feb 19, 2024
@FSG-Cat FSG-Cat marked this pull request as draft February 19, 2024 20:03
@turt2live turt2live added requires-room-version An idea which will require a bump in room version proposal A matrix spec change proposal s2s Server-to-Server API (federation) room-spec Something to do with the room version specifications unassigned-room-version Remove this label when things get versioned. 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 Feb 19, 2024

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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 requires-room-version An idea which will require a bump in room version room-spec Something to do with the room version specifications s2s Server-to-Server API (federation) unassigned-room-version Remove this label when things get versioned.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants