-
Notifications
You must be signed in to change notification settings - Fork 392
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
base: main
Are you sure you want to change the base?
MSC4106: Join as Muted #4106
Conversation
Co-authored-by: Patrick Cloke <[email protected]>
|
||
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. | ||
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Rendered
This MSC enhances membership screening capabilities.
Signed-off-by: Catalan Lover [email protected]