Room-level required opt-in into "new" features #1654
Description
(First of all, sorry if I get some of the terminology wrong, I may not be savvy in Matrix enough.)
Following-on from https://mastodon.matrix.org/@matrix/111167158189489425
Suggestion
"New" (existing) features added to some clients, should require room-level opt-in before being able to be used. The opt-in should be a "property" of the room, where true means the feature is allowed, false means the feature is disallowed, unset means the room default is used.
A special room-level opt-in would exist to say "any new feature allowed". This is the default value for unset specific features. Only when true would the default mean features are allowed. Unset or false imply new features are disallowed.
What does a feature being disallowed mean?
Two main things:
- Clients should not render the new features in a different manner if events are sent referring to a new feature.
- Clients should not allow sending events with the new features (in other words, not expose the feature).
Example
Threads, and any new features as disruptive, should be retroactively grand-childrened into the scope of this.
So, for example, a room that has not opted into Threads:
- Would show existing thread events as in-line events
- Clients would not expose the thread view
Why is this needed? New features are disruptive when not all participants can use them.
The main issue with threads here is that some people will reply "unhooked" to the thread since their client won't even know what a thread is, so they just reply as any other discussions on the main timeline.
This is a moderation issue, since threads also imply that some discussions get lost into a side-channel, and discussions get harder to follow.
As another example, features like voice calls, video calls, should be grand-childrened too, as they are disruptive when accidentally activated in some larger-scale rooms.