MSC4110: Fewer Features

[cloudrac3r]

Rendered

This is hopefully a progression from Poorer Features. Please let me know if I'm on the right track here or if I'm barking up the wrong tree.

Signed-off-by: Cadence Ember [email protected]

[cloudrac3r]

Looking for feedback: Do these make sense? Do they cover all use cases? Does it make sense for them to be ordered like this?

[progval]

In MSC3968 I supported more levels in order to allow expressing "X will be bad over the bridge, but less bad than Y". Not sure that's useful, but at worst clients can ignore the finer levels.

[cloudrac3r]

Is this helpful, or is it not necessary?

[cloudrac3r]

Yep, I think this is helpful. One good use for it is things in the flagship client that are very visible to many users (= high likelihood of being sent by users who expect it to work) but which have an unstable prefix and are still going through the spec. Such as the polls feature, which was in Element for a while but only recently MSC merged.

[tulir]

It is helpful (and even necessary) to note that non-spec extensions can be added, but instead of talking about MSCs specifically, it should just define that all feature identifiers must follow the Common Namespaced Identifier Grammar. That spec already defines that identifiers starting with m. are reserved for specced features, and that custom identifiers following java package naming style are allowed.

There's also no requirement for unstable prefixes in MSCs to use the org.matrix.mscxxxx format even though it's fairly common, any namespaced identifier is a valid unstable prefix.

[cloudrac3r]

Do you mean I should change the feature keys to all start with m.?

[tulir]

Oh right, they currently don't start with that 🤔

Yeah, I think they should be changed, having m. on standard keys makes it clearer that custom keys are allowed too.

[jooooscha]

I would like to see something lile this. But while reading this, I was wondering if this could also be useful for client to client communication. For example, a client could communicate that it does not support threads, or location sharing, or any other client feature.

[cloudrac3r]

@jooooscha To keep discussions organised and to know when they're each resolved, we tend to keep them on the diff. I'm moving your comment to the diff so I can respond to it:

I would like to see something lile this. But while reading this, I was wondering if this could also be useful for client to client communication. For example, a client could communicate that it does not support threads, or location sharing, or any other client feature.

That's an interesting idea. It might be good for less advanced clients to declare Fewer Features in a 1-1 chat, so the other person can avoid using incompatible features. And the trusted_private_chat preset for 1-1 chats allows both people to set any state event, so anybody could add Fewer Features to the room. But I don't think this would scale to group chats. If a single client could disable rich messaging for everyone in the room, that would be a pretty bad experience for everyone else, so we probably shouldn't allow that.

Thoughts?

[jooooscha]

I agree in general. But maybe, the less advanced client could also send Fewer Features to group chats and the more advanced clients decide what to do with it. I am thinking about a more advanced client trying to create a poll, but only one or perhaps none of the other ten group participants can handle polls. It could still be helpful to know that for the creator (client) of the poll.

Not sure if this is in the scope of Fewer Features.

[cloudrac3r]

That's true, it would be cute if when starting a poll in a group chat it could show a notice like "5 of the 10 people in this room can respond to polls". It could be like a larger scale version of a Discouraged feature.

However, I have no idea how to implement this. The Fewer Features proposal relies on state events but regular users can't set state arbitrary state events.

[sumnerevans]

Another complicating factor here is that users may use multiple clients with different capabilities. I normally run Element Desktop, Gomuks, and SchildiChat, all of which have different sets of supported features. It's unclear how I would indicate which of these features I as a user support.

[cloudrac3r]

You're right, it's not realistic to ask human users to manually configure which events they would like to receive. It also (probably?) can't be done automatically by the clients because we can't distinguish between actively used clients and inactively used clients, unless we did some extreme to-device-messaging, which seems out of scope for Fewer Features.

[tezlm]

maybe instead of having the features be an object, it could be a flat hierarchical key~value map, ie.

{
	"reply": -1,
	"replace": -1,
	"formatting.bold": -1,
	"formatting.link": -1,
	"formatting.link.user": -1,
	"formatting.link.event": -1,
	"file": -1,
	"file.image": -1,
    // etc...
}

Then, formatting.link can be set to discourage any links and formatting.link.event could be set to discourage event links specifically. This would also be good for backwards compatibility, since new link type would still be disallowed if formatting.link was set.

[cloudrac3r]

@tezlm As mentioned in "Differences to Poorer Features", I am deliberately limiting entire features rather than individual types, keys, and elements. So I am deliberately not including a way to disable bold formatting.

There is no use case for this because there are no platforms that allow/disallow bold formatting specifically. Even if there was one, the bridge should be able to deal with it, rather than offloading the work onto the client.

If there is a use case then I'm happy to reconsider making it a fine-grained features list like you suggested, but in this proposal I'm currently going with a coarse-grained design because it's the simple option that would be easier for clients to implement.

[progval]

Most IRC servers allow channel operators to disallow (or strip) formatting.

[tulir]

There is no use case for this because there are no platforms that allow/disallow bold formatting specifically. Even if there was one, the bridge should be able to deal with it, rather than offloading the work onto the client.

There are lots of platforms with less formatting features than Matrix even if bold is usually supported. For example:

• Most networks don't support inline images, collapsible blocks (<details>), tables and font colors
• WhatsApp doesn't support spoilers
• Signal doesn't support blockquotes and lists
• Twitter supports user mentions but no other formatting

Bridges can deal with them to some extent, but obviously won't be able to perfectly bridge features that aren't supported. I think there should be a way to tell clients about unsupported features. Some clients may want that info even if other clients won't customize input format based on bridge. I could very well imagine using the goldmark markdown parser in Go and disabling specific features per room.

[cloudrac3r]

OK, seems good! You make good points about both the formatting features on other platforms and how easy it is for clients to implement it. I'll give this a try.

[clokep]

I wonder if maximum message length would make sense as a feature? I think right now if messages are too large they get uploaded by the bridge as a text file to the media repo? That has always felt a bit janky though.

[cloudrac3r]

Good idea, we should add this. Though we'd have to consider that messages might become longer after being converted by the bridge. So even if the client complies with the stated length, the bridge might convert it to something longer and then still have to do some extra work to make the transformed message fit within the limit. (For example, this might happen if the bridged platform's format for user mentions is longer than Matrix's format.)

There's also a question of whether we count the length from body or formatted_body, and if formatted_body, whether we count HTML elements as length. This gets even more complicated for extensible events.

Do you have any ideas how to make this work?

All I can think of is saying the maximum length is a "best guess" and bridges should still be able to handle the situation where it goes over the limit? If this stops Matrix users sending textwalls or pasted code blocks to IRC 90% of the time, that would at least be an improvement...

[progval]

I gave this a shot in MSC3969.

[clokep]

So even if the client complies with the stated length, the bridge might convert it to something longer and then still have to do some extra work to make the transformed message fit within the limit.

That's a good point, I don't have a solution for that unfortunately. Maybe it isn't so useful and bridges just need to handle it.

[progval]

What bridges would convert it to something longer? The IRC bridge always makes it shorter, and most other bridges probably just keep the (X)HTML minus disallowed tags.

[tulir]

I think guessing based on the length of the user input should be good enough. Bridges will generally handle it by rejecting the message, so it'd be nice if users were told before sending at least for messages that are obviously way too long.

[cloudrac3r]

Sure, let's give it a try. @progval do you like the approach you took in MSC3969 (and do you want to continue it?) or do you think we should do it differently in Fewer Features?

[progval]

I haven't tried implementing it, so your guess is as good as mine

[tulir]

I wonder if it'd make more sense to have send values be objects so extra info like reaction limits, file size limits and possibly text length limits could all be in there

{
  "send": {
    "reaction": {
      "desirability": 0,
      "list": ["👍️", "👎️"]
    },
    "file": {
      "desirability": 0,
      "mimetypes": ["image/png", "image/jpeg"],
      "max_size": 102400
    },
    "text": {
      "desirability": 0,
      "max_length": 100
    },
    "sticker": {
      "desirability": 0
    }
  }
}

[tulir]

This should probably also be more granular. For example, Instagram only allows images, videos and voice messages. WhatsApp allows anything when sending as document, but only specific mimetypes when sending as image/video/audio (https://developers.facebook.com/docs/whatsapp/on-premises/reference/media/). I think being able to set mimetype restrictions per msgtype would allow mapping everything properly.

[tulir]

These should have more generic names rather than referencing matrix.to specifically because matrix: URIs also exist (and bridges supporting recent versions of the spec should support both). The spec calls them "User and room mentions", although that could be confused with @room mentions 🤔

[cloudrac3r]

Fair enough, I don't like the name either. I originally picked it because the spec appendix called it out by name.

If I'm going with the hierarchical values from the suggestion above (formatting.bold, formatting.link etc) I'll put them under formatting.link.room and formatting.link.user which I think works pretty well. After all, the matrix.to room links really behave like room links and not mentions.

[tulir]

Lines should be wrapped to 120 characters at most

[tulir]

I'm not completely sure if this is a good idea or not. There are several networks that only allow one reaction per message, but my bridges already handle that by automatically redacting the previous reaction. If the client were to do the redaction, then the bridge would bridge that removal over to the remote network first, instead of just making a single API call to replace the reaction.

[cloudrac3r]

There are several networks that only allow one reaction per message, but my bridges already handle that by automatically redacting the previous reaction.

That's a smart idea for handling it, nice!

I'm not completely sure if this is a good idea or not.

As far as I'm aware, our choices are:

1. Assume all bridge developers thought of this idea and implemented it in their bridge, and so remove reactions_per_event from the proposal because it isn't needed
2. Assume some bridge developers didn't think of this idea or weren't able to implement it, and keep reactions_per_event to be used by bridges that can't handle this situation themselves
3. Keep reactions_per_event anyway so that some clients can provide graphical feedback

Do you have a favourite choice?

[tulir]

If there was a way to say "limited to X reactions, but the bridge will redact the previous one automatically" it would accurately represent what happens now, but I'm not sure if that's actually useful to clients. I guess clients could have a "local echo" type thing where they hide the previous reaction locally immediately rather than waiting for the redaction? That would provide the best UX in the happy path, but would cause weirdness if the bridge fails to do the redaction for whatever reason.

Other than that, might be fine to keep it around even if it's not used

[tulir]

Another thing this reminded me of: Telegram allows 3 reactions for premium users and 1 reaction for normal users. Some platforms also have per-user limits for things like file size and message length. I think it's fine not to solve such cases here, but should probably be noted in potential issues.

[tulir]

clients MUST still allow the user to redact the event on Matrix-side

I'm not sure if the spec is allowed to have such strong wording about client UI, SHOULD would probably be more appropriate. Also, rooms can already prevent users from redacting messages by setting the m.room.redaction event power level to non-default value.

[cloudrac3r]

Also, rooms can already prevent users from redacting messages by setting the m.room.redaction event power level to non-default value.

Rooms can prevent users redacting their own events?? I can't believe Matrix allows that. I'll update my proposal to not have that assumption.

[tulir]

Just remembered another type of limit that many other networks have: maximum number of edits and maximum time after sending that message can be edited. Similarly, redactions also have a time limit on some networks.

[tulir]

Beeper is planning on using a different format, which is documented at https://github.com/mautrix/go/blob/main/event/capabilities.d.ts

Notable differences:

• Each file message type is handled separately, with allowed mime types listed
• Formatted text is split into features to allow signaling exactly what's supported
• Levels range from -2 to 2 instead of -3 to 0