MSC3909: Membership based mutes #3909
Conversation
FSG-Cat
changed the title
turt2live
added
proposal
Co-authored-by: Aminda Suomalainen <suomalainen+git@mikaela.info>
|
I wonder if there's another way to approach this that would allow users to rejoin as muted (which I would want to allow from a policy perspective with how I use mutes, personally - eg imagine if #55 is implemented and I do an IP mute space-wide of a classroom because of misbehavior but still want them to see activity). What would be the tradeoffs of a separate |
| @@ -0,0 +1,88 @@ | |||
| # MSC3909: Membership based mutes | |||
There was a problem hiding this comment.
@luxaritas putting this as a thread as its the correct way to do things.
A leave-mute membership state would actually bypass the issue that requires currently self banning. Because the rule could be that leave is only legal via kick and self leaves are instead leave-mutes and for leave mute the only legal self initiated transition is mute meaning you would essentially gain sticky mutes and bypass this whole self ban stuff. Its quite a good solution to the problem to be honest and it bypasses the whole concern of mine of having to look multiple layers deep in the chain to evaluate legality.
There was a problem hiding this comment.
Oops yeah sorry I didn't comment in-line!
Nico pointed out in a conversation the issue of that EDU definition was unclear and that we should allow redactions. Ban transitions where also fixed as they had been overlooked.
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
|
|
||
| their membership to `leave-mute` as defined later and `m.room.redaction` events. | ||
|
|
||
| This proposal also introduces the new membership type of `leave-mute` this special membership |
There was a problem hiding this comment.
The spec generally seems to use snake_case rather than kebab-case.
|
|
||
| their membership to `leave-mute` as defined later and `m.room.redaction` events. | ||
|
|
||
| This proposal also introduces the new membership type of `leave-mute` this special membership |
There was a problem hiding this comment.
Considering that people would muted users to be able to be invited and knock on rooms, I feel like it might just make more sense to add an additional field to the m.room.member event, rather than having to double the number of membership states.
Rendered
MSC Co Authored by @FSG-Cat and @Gnuxie
Signed-off-by: Catalan Lover catalanlover@protonmail.com