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.