MSC4060: Accept room rules before speaking #4060
Conversation
turt2live
added
proposal
| 3. [Event relationships](https://spec.matrix.org/v1.8/client-server-api/#forming-relationships-between-events) - | ||
| like we've done for pretty much everything else. | ||
|
|
||
| When `m.room.rules` is present in a room, and the user hasn't accepted them, the |
There was a problem hiding this comment.
Presumably, if a new m.room.rules event is sent, everyone will need to accept the new rules, even if they had previously accepted the old rules. (Which means, among other things, that if a client sees a new m.room.rules state event, it should re-prompt the user to accept it.)
| This MSC deliberately does not tie acceptance of the rules into the event | ||
| authorization algorithm. Doing so with the current power level structure in | ||
| Matrix rooms could potentially lead to over-imposed opinions on what it means | ||
| to "speak" in a room, as well as requiring users to frequently accept rule | ||
| changes. |
There was a problem hiding this comment.
In my understanding this MSC is limited in this way to keep it small and simple?
As far as I see, there is a trade-off of initially not offering the customizability of
- "what it means to speak"
- how to deal with rule updates
- maybe something I am not seeing or perhaps I am missing some specific context this is trying to address
and the worse UX and community admin effort of (creating,) setting up, and maintaining a bot that handles these.
While I think the additional effort is clear, the "worse UX" could mean e.g.
- a bot redacts messages and posts a "please accept the rules" message -> spammy and disruptive to the rest of the community, especially if in a big community this happens constantly
- a bot manages the PL to disallow sending at all, while no user feedback is possible (composer will only say "you can't send messages" and not "please accept the rules")
Most of this will then later become obsolete when a follow-up MSCs expands the possibilities.
Is this trade-off worth it to not make a bigger throw from the start? I would like to see further explanation why.
Rendered