Ability to disable richer features per room or space.

[ara4n]

matrix-org/matrix-appservice-irc#1301 adds the ability to specify per-room configuration for the IRC bridge, to configure how things like long messages are pastebinned or the formats used for relaying replies.

However, we don't have the ability in general for a room/space admin to recommend that certain features are not used in a given room (unless they're features which map to specific event types which could be blocked by PLs). But for enforcing cultural norms in a room, or for moderation, or managing bridging impedance-mismatches, this could be a super useful feature.

So, I think we should define a config format which recommends how clients should be behave in terms of:

• The maximum length of messages sent to a room
• The maximum number of lines in messages sent to a room
• Whether files are allowed in the room
• Whether images/videos are allowed in a room
• Whether stickers allowed in a room
• Whether voice messages are allowed in a room
• What text formats are allowed
• Whether colours/colors/rainbows are allowed
• Whether edits are allowed
• Whether replies are allowed
• Whether reactions are allowed (although these could be blocked via PLs)
• Whether visual effects like confetti are allowed (see also Upgrade showChatEffects to room-level setting exposure matrix-react-sdk#6075)

A well-behaved client SHOULD then honour these restrictions in its UI when sending content (although in general these are recommendations and are not enforced by the servers).

In future, once matrix-org/matrix-spec-proposals#1767 lands, we could also enforce more of these by blocking the event types using PLs (e.g. blocking files/images/edits/replies/reactions).

This in turn would make IRC bridging way nicer, as the bridge could configure portal rooms by default to have no edits/replies etc, and so eliminate the hate that Matrix gets for that impedance mismatch - while still letting room admins loosen the restriction if they care.

(P.S. i can't believe we don't have this already, but I've looked and failed to find a bug for it).

[ara4n]

Oh, and a nice extension would be to be able to override the config per-user, so you can (say) whitelist a bot to use colours, while stopping all the other random users from spamming rainbows everywhere.

[MTRNord]

Not sure if matrix-org/matrix-spec-proposals#3006 and matrix-org/matrix-spec-proposals#2346 are/should be related? Atleast the MSC by halfshot probably could be related as it already covers the displaying side of bridges.

[ara4n]

n.b. this is absolutely not bridge specific though - this is a general "hey, in this Matrix room, we don't want clients sending rainbows, thanks."

[MTRNord]

Ah so more something like event defined room capabilities?

[ara4n]

Capabilities implies something which can be enforced, whereas this is just advisory. It's more saying "the social norms of this room are to not send edits, plz".

[turt2live]

it might be interesting to take linter semantics into consideration for off/warn/error levels, though that might also be completely overkill.

[ara4n]

😱

[Half-Shot]

Some prior art here. Annoyingly I never found time to finish it, but as far as limits go this was how I'd have gone about it.

[kevincox]

Oh, and a nice extension would be to be able to override the config per-user, so you can (say) whitelist a bot to use colours, while stopping all the other random users from spamming rainbows everywhere.

Since this is advisory anyways I think it is better to just tell the bot that it can use colour or whatever (and ignore the recommendation here). It does mean that we are pushing work onto bots (generic bots may follow these by default and need an option to override it) but I think it is probably better overall. Especially since you may want to configure this by "message type" anyways which is not a Matrix concept. (For example use colours for "Build Failure" messages but everything else should respect the config in the room).

it might be interesting to take linter semantics into consideration for off/warn/error levels, though that might also be completely overkill.

I thought the exact same thing. However the more I think about the more sense I think it makes. See these use cases

• Warn: "This room is bridged to other networks which don't support $feature, some members may be confused."
• Error: "$feature is against room policy. [Send Anyways]"
• Different severity based on message length. For example Warn for >1 IRC line, error at >5.

I'm also wondering if we should provide custom error messages. (This could replace the need for warn/error somewhat). This will help users understand why the limits are in place and who they will be confusing. For example if the error message is "Discord and IRC users won't see reactions" you may still react to a Matrix user if it isn't critical to the conversation. (For example 😆 or 🙄 to a "good" pun).

[olmari]

So in essence, potentially make matrix dumber because irc exist? :) This would be okay on portal room, which are exactly irc-rooms to begin with (conceptually), plumbs are way harder conceptually.

[Mikaela]

As an example that has nothing to do with IRC or other bridges, I would like to disable reactions in encrypted rooms as I tend to use /react as do my friends, and we don't remember all the time that reactions are unencrypted. Ref: #660

[julianfoad]

Use cases around the theme of simplifying client UI:

• Grandparents are intimidated by a busy complex UI (buttons for markdown mode, video / voice call, emoji, different kinds of attachment, etc.) -> the family's space-admin sets these features to either "off (advisory)" or "off (enforced)" -> matrix clients simplify their UI by hiding the buttons.
• A feature-rich Matrix client wants to prioritize which of its many possible buttons to show -> uses this info to hide unwanted ones (and still is a power-user UI).

[MTRNord]

Another example would be that I as a room admin don't want voice messages in my rooms as I cannot moderate them on the fly (can't listen to them in a car or train for example). So I would love to disable them fully.

[Mikaela]

Another case is that some rooms would like to disable threads that Element appears to be forcing on everyone while many in the room prefer to use FluffyChat or Hydrogen that don't currently have threads and I am not sure it even fits the goal of FluffyChat.

[progval]

I am proposing a set of complementary solutions to address this:

1. forbid event types that cannot be bridged, using power levels. Element Web (and probably other clients) gracefully handle this, eg. by hiding the "react" button when they do not have the required m.reaction PL. Example on IRC DM rooms
2. MSC3968: filter specific features of event types by signaling which are undesirable; this should be eventually enforced by receiving clients
3. MSC3969: for the remaining issue: size and line limits

[ptman]

While I understand the approach of advisory limits, I think this really should be enforcable via room permissions. Threads could be added to the list.

[julianfoad]

Re. the "firmness" scale. Currently "MSC3968: Poorer features" defines a sliding integer scale of "firmness" while "MSC3969: Size limits" defines "soft/hard". This difference seems an unnecessary distraction. I would expect any kind of feature restriction to have similar semantics and representations for "firmness". Can you pick one way and unify them? I realise it's not initially clear which way is "best", but consistency is good. My gut feeling is the sliding scale would actually end up costing considerably more effort (in total, from specification through implementations through usage subtleties) than the value of the supposed finesse it could offer. KISS.

[progval]

@julianfoad Conceptually, MSC3968 is also soft/hard with the <0 and <=100 limits, but the integer levels allow "tie-breaking" when a client has to choose between two mutually-exclusive options (eg. displaying one button more prominently than another). This doesn't make sense for size limits, because there are no mutually-exclusive options.

[MTRNord]

Coming from #1931 it would also be nice to have this feature set be "scopeable". Meaning that I can decide to apply different feature sets to the "main timeline" vs thread timelines.

I am aware that this is a UI design not all clients follow, and yet I think it is a good idea on the spec level to have this difference.

This would allow for rooms where you have full features in threads but a less noisy main timeline. This is especially important as current clients generally display the parent message of a reply in its full length. So you end up with having a single message multiple times in the timeline. This is especially bad when that message is already filling the screen. So disabling for examples replies but allowing threads in the main timeline would cause a preference of threads over replies but won't restrict replies within a discussion happening inside of a thread. This would be amazing for rooms like twim where noise can at certain days get very annoying while not preventing discussions. TLDR: It solves a signal-to-noise issue while not being overly disruptive with the solution used.

Additionally, as suggested by travis in a discussion in the spec room, it could be a good idea to have the option "yes/no/only" for threads instead of just a boolean "yes/no".

Also, important difference from the original suggestion is that I would expect servers to enforce things like "replies off" when checking if the event can be sent. Since otherwise this could cause imho some weird sideffects down the line.

[tulir]

For reference, MSC3968 was closed and MSC4110 was opened to replace it

[samueldr]

(Since #1654 has been closed, which is fair...)

Features must preferably be considered opt-in.

In other words, the room, and thus its users, should have to consent into new features being available, rather than end-up scrambling to deal with a new feature their client(s) may not recognize or work well with.