MSC3952: Intentional Mentions (#3952)
parent
0907871400
commit
8b6e2afcea
@ -0,0 +1,633 @@
|
||||
# MSC3952: Intentional Mentions
|
||||
|
||||
Mentioning other users on Matrix is difficult -- it is not possible to know if
|
||||
[mentioning a user by display name or Matrix ID](https://github.com/matrix-org/matrix-spec/issues/353)
|
||||
will count as a mention, but is also too easy to mistakenly mention a user.
|
||||
|
||||
(Note that throughout this proposal "mention" is considered equivalent to a "ping"
|
||||
or highlight notification.)
|
||||
|
||||
Some situations that result in unintentional mentions include:
|
||||
|
||||
* Replying to a message will re-issue pings from the initial message due to
|
||||
[fallback replies](https://spec.matrix.org/v1.5/client-server-api/#fallbacks-for-rich-replies).
|
||||
* A user without the power level to send `@room` can abuse this by including
|
||||
`@room` in a message and getting a user with the appropriate power levels
|
||||
to reply to them.
|
||||
* Each time a message is edited the new version will be re-evaluated for mentions.
|
||||
* Mentions occurring [in spoiler contents](https://github.com/matrix-org/matrix-spec/issues/16)
|
||||
or [code blocks](https://github.com/matrix-org/matrix-spec/issues/15) are
|
||||
evaluated.
|
||||
* If the [localpart of your Matrix ID is a common word](https://github.com/matrix-org/matrix-spec-proposals/issues/3011)
|
||||
then the push rule matching usernames (`.m.rule.contains_user_name`) matches
|
||||
too often (e.g. Travis CI matching if your Matrix ID is `@travis:example.org`).
|
||||
* If the [localpart or display name of your Matrix ID matches the hostname](https://github.com/matrix-org/matrix-spec-proposals/issues/2735)
|
||||
(e.g. `@example:example.org` receives notifications whenever `@foo:example.org`
|
||||
is replied to).
|
||||
|
||||
As a sender you do not know if including the user's display name or Matrix ID would
|
||||
even be interpreted as a mention (see [issue 353](https://github.com/matrix-org/matrix-spec/issues/353)).
|
||||
This results in some unexpected behavior and bugs:
|
||||
|
||||
* Matrix users use "leetspeak" when sending messages to avoid mentions (e.g.
|
||||
referring to M4tthew instead of Matthew).
|
||||
* It is impossible to ping one out of multiple people with the same localpart
|
||||
(or display name).
|
||||
* Since the relation between `body` and `formatted_body` is ill-defined and
|
||||
["pills" are converted to display names](https://github.com/matrix-org/matrix-spec/issues/714),
|
||||
this can result in missed messages. [^1]
|
||||
|
||||
There are also some other related bugs:
|
||||
|
||||
* Matrix users will append emoji or other unique text in their display names to
|
||||
avoid unintentional pings.
|
||||
* Bridging mentions is suboptimal since they [use display names](https://github.com/matrix-org/matrix-spec/issues/353#issuecomment-1055809364)
|
||||
as a workaround, e.g.:
|
||||
* It breaks the contract that bridges will not mutate the content of messages.
|
||||
* For some protocols, bridges need try to figure out if every message contains
|
||||
any of the possible nicknames of room members.
|
||||
* If a user changes their display name in a room,
|
||||
[they might not be mentioned unless the historical display name](https://github.com/matrix-org/matrix-spec/issues/353#issuecomment-1055809372)
|
||||
is used while processing push rules.
|
||||
|
||||
## Background
|
||||
|
||||
Mentions are powered by two of the default push rules that search an event's
|
||||
`content.body` property for the current user's display name
|
||||
([`.m.rule.contains_display_name`](https://spec.matrix.org/v1.5/client-server-api/#default-override-rules))
|
||||
or the localpart of their Matrix ID ([`.m.rule.contains_user_name`](https://spec.matrix.org/v1.5/client-server-api/#default-content-rules)).
|
||||
|
||||
There's also a [section about "user and room mentions"](https://spec.matrix.org/v1.5/client-server-api/#user-and-room-mentions)
|
||||
which defines that messages which mention the current user in the `formatted_body`
|
||||
of the message should be colored differently:
|
||||
|
||||
> If the current user is mentioned in a message (either by a mention as defined
|
||||
> in this module or by a push rule), the client should show that mention differently
|
||||
> from other mentions, such as by using a red background color to signify to the
|
||||
> user that they were mentioned.
|
||||
|
||||
## Proposal
|
||||
|
||||
The existing push rules for user and room mentions are deprecated and new rules,
|
||||
which use a property specific for mentions[^2], are added to make mentions simpler
|
||||
and more reliable for users.
|
||||
|
||||
### New event property
|
||||
|
||||
A new `m.mentions` property is added to the event content; it is an object with two
|
||||
optional properties:
|
||||
|
||||
* `user_ids`: an array of strings consisting of Matrix IDs to mention.
|
||||
* `room`: a boolean, true indicates an "@room" mention. Any other value or the
|
||||
property missing is interpreted as not an "@room" mention.
|
||||
|
||||
It is valid to include both the `user_ids` and `room` properties.
|
||||
|
||||
It is recommended that homeservers reject locally created events with an invalid
|
||||
`m.mentions` property with an error with a status code of `400` and an errcode of
|
||||
`M_INVALID_PARAM`.
|
||||
|
||||
Clients add a Matrix ID to the `user_ids` array whenever composing a message which
|
||||
includes an intentional mention, such as a ["pill"](https://spec.matrix.org/v1.5/client-server-api/#user-and-room-mentions).
|
||||
Clients set the `room` value to `true` when making a room-wide announcement. Clients
|
||||
should also set these values at other times when it is obvious the user intends to explicitly
|
||||
mention a user.[^3]
|
||||
|
||||
The `m.mentions` property is part of the plaintext event body and should be encrypted
|
||||
into the ciphertext for encrypted events.
|
||||
|
||||
### New push rules
|
||||
|
||||
Two new default push rule are added.
|
||||
|
||||
The `.m.rule.is_user_mention` override push rule would appear directly
|
||||
before the `.m.rule.contains_display_name` push rule:
|
||||
|
||||
```json
|
||||
{
|
||||
"rule_id": ".m.rule.is_user_mention",
|
||||
"default": true,
|
||||
"enabled": true,
|
||||
"conditions": [
|
||||
{
|
||||
"kind": "event_property_contains",
|
||||
"key": "content.m\\.mentions.user_ids",
|
||||
"value": "[the user's Matrix ID]"
|
||||
}
|
||||
],
|
||||
"actions": [
|
||||
"notify",
|
||||
{
|
||||
"set_tweak": "sound",
|
||||
"value": "default"
|
||||
},
|
||||
{
|
||||
"set_tweak": "highlight"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
(Note: `\\.` would become a single logical backslash followed by a dot since the
|
||||
above is in JSON-representation. See
|
||||
[MSC3873](https://github.com/matrix-org/matrix-spec-proposals/pull/3873).)
|
||||
|
||||
The `.m.rule.is_room_mention` override push rule would appear directly
|
||||
before the `.m.rule.roomnotif` push rule:
|
||||
|
||||
```json
|
||||
{
|
||||
"rule_id": ".m.rule.is_room_mention",
|
||||
"default": true,
|
||||
"enabled": true,
|
||||
"conditions": [
|
||||
{
|
||||
"kind": "event_property_is",
|
||||
"key": "content.m\\.mentions.room",
|
||||
"value": true
|
||||
},
|
||||
{
|
||||
"kind": "sender_notification_permission",
|
||||
"key": "room"
|
||||
}
|
||||
],
|
||||
"actions": [
|
||||
"notify",
|
||||
{
|
||||
"set_tweak": "highlight"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
An example event matching both `.m.rule.is_user_mention` (for `@alice:example.org`)
|
||||
and `.m.rule.is_room_mention` is provided below:
|
||||
|
||||
```json
|
||||
{
|
||||
"content": {
|
||||
"body": "This is an example mention @alice:example.org",
|
||||
"format": "org.matrix.custom.html",
|
||||
"formatted_body": "<b>This is an example mention</b> <a href='https://matrix.to/#/@alice:example.org'>Alice</a>",
|
||||
"msgtype": "m.text",
|
||||
"m.mentions": {
|
||||
"user_ids": ["@alice:example.org"],
|
||||
"room": true
|
||||
}
|
||||
},
|
||||
"event_id": "$143273582443PhrSn:example.org",
|
||||
"origin_server_ts": 1432735824653,
|
||||
"room_id": "!somewhere:over.the.rainbow",
|
||||
"sender": "@example:example.org",
|
||||
"type": "m.room.message",
|
||||
"unsigned": {
|
||||
"age": 1234
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Client behavior
|
||||
|
||||
The overall user experience is not modified, beyond improving explicitness and
|
||||
reducing unintended mentions.
|
||||
|
||||
For example, it is common that a client will show an event with a mention in a
|
||||
different color (and denote the current user's "pill", as a way of showing the
|
||||
user *why* they were mentioned). This behavior is unchanged.
|
||||
|
||||
There are two variations that clients should take into account when decorating
|
||||
messages for mentions, however:
|
||||
|
||||
* The presence of a user's "pill" in a message no longer implies it is a mention.
|
||||
* This makes it easier to mention users without including their "pill" in a
|
||||
message (see [Abuse Potential](#abuse-potential) for ideas to combat this).
|
||||
|
||||
### Backwards compatibility
|
||||
|
||||
The [`.m.rule.contains_display_name`](https://spec.matrix.org/v1.5/client-server-api/#default-override-rules),
|
||||
[`.m.rule.contains_user_name`](https://spec.matrix.org/v1.5/client-server-api/#default-content-rules),
|
||||
and [`.m.rule.roomnotif`](https://spec.matrix.org/v1.5/client-server-api/#default-override-rules)
|
||||
push rules are to be deprecated.
|
||||
|
||||
To avoid unintentional mentions these rules are modified to only apply when the
|
||||
`m.mentions` property is missing; clients should provide at least an empty `m.mentions` property on
|
||||
every message to avoid the unintentional mentions discussed in the introduction.
|
||||
|
||||
A future room version may wish to disable the legacy push rules: clients would
|
||||
no longer be required to include the `m.mentions` property on every event. It
|
||||
maybe convenient to do this when extensible events are adopted (see
|
||||
[MSC3932](https://github.com/matrix-org/matrix-spec-proposals/pull/3932)).
|
||||
|
||||
After acceptance, it is likely for there to be disagreement about which push rules are
|
||||
implemented: legacy clients and homeservers may not yet have deprecated the
|
||||
`.m.rule.contains_display_name`, `.m.rule.contains_user_name`, and `.m.rule.roomnotif`
|
||||
push rules, while up-to-date clients and homeservers will support the
|
||||
`.m.rule.is_user_mention` and `.m.rule.is_room_mention` push rules. It is expected
|
||||
that both sets of push rules will need to be supported for a period of time, but
|
||||
at worst case should simply result in the current behavior (documented in the preamble).
|
||||
|
||||
If users wish to continue to be notified of messages containing their display name
|
||||
it is recommended that clients create a specific keyword rule for this, e.g. a
|
||||
`content` rule of the form:
|
||||
|
||||
```json
|
||||
{
|
||||
"actions": [
|
||||
"notify",
|
||||
{
|
||||
"set_tweak": "sound",
|
||||
"value": "default"
|
||||
},
|
||||
{
|
||||
"set_tweak": "highlight"
|
||||
}
|
||||
],
|
||||
"pattern": "alice",
|
||||
"rule_id": "alice",
|
||||
"enabled": true
|
||||
}
|
||||
```
|
||||
|
||||
### Impact on replies
|
||||
|
||||
Users are notified of replies via the `.m.rule.contains_display_name` or the
|
||||
`.m.rule.contains_user_name` push rule matching the
|
||||
[rich reply fallback](https://spec.matrix.org/v1.6/client-server-api/#fallbacks-for-rich-replies).
|
||||
Unfortunately these push rules will be disabled for events which contain the
|
||||
`m.mentions` property, i.e. all newly created events (see
|
||||
[above](#backwards-compatibility)). Clients should include the sender of the event
|
||||
being replied to as well as any mentioned users in that event (excluding yourself)
|
||||
in the new event's `m.mentions` property. The `room` property MUST NOT be copied over.
|
||||
|
||||
This signals that it is the *intention* of the sender to mention all of those people.
|
||||
This behavior may not make sense in all situations (e.g. an email-like client could
|
||||
provide both a "reply" and "reply all", while a microblogging client may wish to
|
||||
provide a "quote reply", dropping all mentions from the original event) and clients
|
||||
may wish to allow users to modify the list of mentioned users.
|
||||
|
||||
For example, if there is an event:
|
||||
|
||||
```json5
|
||||
{
|
||||
"sender": "@dan:example.org",
|
||||
"event_id": "$initial_event",
|
||||
"content": {
|
||||
"body": "Alice: Have you heard from Bob?",
|
||||
"m.mentions": {
|
||||
"user_ids": ["@alice:example.org", "@bob:example.org"]
|
||||
}
|
||||
},
|
||||
// other fields as required by events
|
||||
}
|
||||
```
|
||||
|
||||
And a reply from Alice:
|
||||
|
||||
```json5
|
||||
{
|
||||
"content": {
|
||||
"body": "> <@dan:example.org> Alice: Have you heard from Bob?\n\nNo, but I saw him with Charlie earlier.",
|
||||
"m.mentions": {
|
||||
"user_ids": [
|
||||
// Include the sender of $initial_event (optional).
|
||||
"@dan:example.org",
|
||||
// The users mentioned, minus yourself (optional).
|
||||
"@bob:example.org",
|
||||
// New mentions, as normal.
|
||||
"@charlie:example.org"
|
||||
]
|
||||
},
|
||||
"m.relates_to": {
|
||||
"m.in_reply_to": {
|
||||
"event_id": "$initial_event"
|
||||
}
|
||||
}
|
||||
},
|
||||
// other fields as required by events
|
||||
}
|
||||
```
|
||||
|
||||
If a user wishes to be notified of *all replies* to their messages, other solutions
|
||||
should be investigated, such as [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664).
|
||||
This would give more equal power to both senders and receivers of events.
|
||||
|
||||
### Impact on edits
|
||||
|
||||
Similarly to [replies](#impact-on-replies), users are notified of message edits
|
||||
via the `.m.rule.contains_display_name` or the `.m.rule.contains_user_name` push
|
||||
rule matching the [fallback content](https://spec.matrix.org/v1.6/client-server-api/#event-replacements).
|
||||
Generally this is undesirable and users do not need to be notified for the same
|
||||
message multiple times (e.g. if a user is fixing a typo).
|
||||
|
||||
Replacement events may have `m.mentions` properties in two locations:
|
||||
|
||||
* One at the top-level of the `content`, which should contain any users to mention
|
||||
*for this edit*.
|
||||
* One inside the `m.new_content` property, which should contain the full list of
|
||||
mentioned users in any version of the event, unless a mention is removed
|
||||
(see below).
|
||||
|
||||
It is recommended that clients use an empty top-level `m.mentions` property when
|
||||
editing an event, *unless* the edit is significant or if additional users are
|
||||
mentioned in the latest version.
|
||||
|
||||
For example, if there is an event:
|
||||
|
||||
```json5
|
||||
{
|
||||
"sender": "@dan:example.org",
|
||||
"event_id": "$initial_event",
|
||||
"content": {
|
||||
"body": "Hello Alice!",
|
||||
"m.mentions": {
|
||||
"user_ids": ["@alice:example.org"]
|
||||
}
|
||||
},
|
||||
// other fields as required by events
|
||||
}
|
||||
```
|
||||
|
||||
And an edit after realizing that Bob is also in the room:
|
||||
|
||||
```json5
|
||||
{
|
||||
"content": {
|
||||
"body": "* Hello Alice & Bob!",
|
||||
"m.mentions": {
|
||||
"user_ids": [
|
||||
// Include only the newly mentioned user.
|
||||
"@bob:example.org"
|
||||
]
|
||||
},
|
||||
"m.new_content": {
|
||||
"body": "Hello Alice & Bob!",
|
||||
"m.mentions": {
|
||||
"user_ids": [
|
||||
// Include all mentioned users.
|
||||
"@alice:example.org",
|
||||
"@bob:example.org"
|
||||
]
|
||||
},
|
||||
},
|
||||
"m.relates_to": {
|
||||
"rel_type": "m.replace",
|
||||
"event_id": "$initial_event"
|
||||
}
|
||||
},
|
||||
// other fields as required by events
|
||||
}
|
||||
```
|
||||
|
||||
Mentions can also be removed as part of an edit. In this case, the top-level `m.mentions`
|
||||
property would not include the removed user IDs (you cannot cancel the notification from
|
||||
the previous event) or any previously notified users, and the removed user would also be
|
||||
removed from the `m.new_content` proprerty's copy of `m.mentions`.
|
||||
|
||||
This should limit duplicate, unnecessary notifications for users. If a user wishes
|
||||
to receive notifications for edits of events they were mentioned in then they
|
||||
could setup a push rule for the `content.m\\.new_content.m\\.mentions` property
|
||||
or potentially leverage [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664).
|
||||
|
||||
This implies that:
|
||||
|
||||
* If a client highlights a message visually (e.g. by coloring it red), then it
|
||||
should look at the `m.mentions` under `m.new_content` for edited messages.
|
||||
Otherwise, in the example above, Alice would not see the message as red, even
|
||||
though the intent was for her to be mentioned.
|
||||
* Any sort of processing of push rules, e.g. to display a notification (sound,
|
||||
toast, push notification), should occur without any special rules. I.e. the
|
||||
`.m.rule.is_user_mention` and `.m.rule.is_room_mention` should look at the
|
||||
`m.mentions` directly under `content` and not match for Alice.
|
||||
|
||||
### Impact on bridging
|
||||
|
||||
For protocols with a similar mechanism for listing mentioned users this should
|
||||
strengthen the bridging contract as it enables bridges to stop mutating the
|
||||
content of messages. The bridge should be able to map from the remote user ID
|
||||
to the bridged user ID and include that in the `m.mentions` property of the
|
||||
Matrix event & the proper field in the bridged protocol[^4].
|
||||
|
||||
For bridged protocols that do not have this mechanism, the bridge will only
|
||||
be able to stop mutating content on messages bridged *into* Matrix. Messages
|
||||
bridged out of Matrix will still need to embed the mention into the text
|
||||
content.[^5]
|
||||
|
||||
## Potential issues
|
||||
|
||||
### Abuse potential
|
||||
|
||||
This proposal makes it trivial to "hide" mentions since it does not require the
|
||||
mentioned Matrix IDs to be part of the displayed text. This is only a limitation
|
||||
for current clients: mentions could be exposed in the user interface directly.
|
||||
For example, a de-emphasized "notified" list could be shown on messages, similar
|
||||
to CCing users on an e-mail.
|
||||
|
||||
Although not including mentions in the displayed text could be used as an abuse
|
||||
vector, it does not enable additional malicious behavior than what is possible
|
||||
today. From discussions and research while writing this MSC there are moderation
|
||||
benefits to using a separate property for mentions:
|
||||
|
||||
* The number of mentions is trivially limited by moderation tooling, e.g. it may
|
||||
be appropriate for a community room to only allow 10 mentions. Events not abiding
|
||||
by this could be rejected automatically (or users could be banned automatically).
|
||||
* Various forms of "mention bombing" are no longer possible.
|
||||
* It is simpler to collect metrics on how mentions are being used (it is no longer
|
||||
necessary to process the textual `body` for every user's display name and local
|
||||
part).
|
||||
|
||||
Overall this proposal seems to be neutral or positive in the ability to combat
|
||||
malicious behavior.
|
||||
|
||||
### Encrypted mentions & `/notifications`
|
||||
|
||||
A previous version of this proposal (and the alternative [MSC1796](https://github.com/matrix-org/matrix-spec-proposals/pull/1796))
|
||||
suggested leaving the `m.mentions` property in cleartext. This was
|
||||
[deemed too large of a metadata leak](https://github.com/matrix-org/matrix-spec-proposals/pull/3952#discussion_r1112154200)
|
||||
and removed from this proposal (and MSC1796 was closed). A downside of this is
|
||||
that homeservers (still) will not be able to differentiate between notifications
|
||||
and mentions in many cases.
|
||||
|
||||
This mostly affects how often homeservers push to devices (see
|
||||
[MSC3996](https://github.com/matrix-org/matrix-spec-proposals/pull/3996)
|
||||
for more information), but also means that the `/notifications?only=highlight`
|
||||
API is not useful in encrypted rooms.
|
||||
|
||||
## Future extensions
|
||||
|
||||
### Combating abuse
|
||||
|
||||
Some ideas for combating abuse came from our discussion and research which are
|
||||
worth sharing. These ideas are not a requirement for implementing this MSC, and
|
||||
generally do not depend on it. (They could be implemented today with enough effort.)
|
||||
|
||||
It was recommended that clients could expose *why* an event has caused a notification
|
||||
and give users inline tools to combat abuse. For example, a client might show a tooltip:
|
||||
|
||||
> The sender of the message (`@alice:example.org`) mentioned you in this event.
|
||||
>
|
||||
> Block `@alice:example.org` from sending you messages? `[Yes]` `[No]`
|
||||
|
||||
Additionally, if a user sending a message is about to mention many people it can
|
||||
be useful to confirm whether they wish to do that (or prompt them to do an `@room`
|
||||
mention instead).
|
||||
|
||||
Moderators may find tooling to quickly find messages which mention many users
|
||||
useful in combating mention spammers. (Note that this should be made easier by
|
||||
this MSC.)
|
||||
|
||||
A future MSC might wish to explore features for trusted contacts or soft-ignores
|
||||
to give users more control over who can generate notifications.
|
||||
|
||||
### Muted except for mentions push rules
|
||||
|
||||
It might be desirable to have a "muted-except-for-mentions" feature for large (encrypted)
|
||||
rooms. This is particularly useful on iOS where a push notification can be decrypted
|
||||
via a background process but *cannot* be suppressed. This means it is not possible
|
||||
for the client to handle this feature and it must be handled on the server, unfortunately
|
||||
this would not be possible with the current proposal since the `m.mentions`
|
||||
property is encrypted (and the server cannot act on it).
|
||||
|
||||
Solving this problem is left to a future MSC, such as [MSC3996](https://github.com/matrix-org/matrix-spec-proposals/pull/3996)
|
||||
which builds on this proposal.
|
||||
|
||||
### Pillifying `@room`
|
||||
|
||||
Some clients attempt to create a "pill" out of `@room` mentions, but this is not
|
||||
a requirement of the Matrix specification. The current [user and rooms mentions](https://spec.matrix.org/v1.5/client-server-api/#user-and-room-mentions)
|
||||
section could be expanded for this situation.
|
||||
|
||||
### Extensible events
|
||||
|
||||
Handling of this property in [MSC1767](https://github.com/matrix-org/matrix-doc/pull/1767)-style
|
||||
extensible events is deliberately left for a future MSC to address, if needed.
|
||||
|
||||
### Role mentions
|
||||
|
||||
It is possible to add additional properties to the `m.mentions` object, e.g. a foreseeable
|
||||
usecase would be a `roles` property which could include values such as `admins` or
|
||||
`mods`. Defining this in detail is left to a future MSC.
|
||||
|
||||
### Cancelling notifications
|
||||
|
||||
It might be useful for a future MSC to investigate cancelling notifications if a
|
||||
user's mention is removed while [editing events](#impact-on-edits). This could
|
||||
be quite difficult as it is unclear if the mentioned user has already received
|
||||
the notification or not.
|
||||
|
||||
## Alternatives
|
||||
|
||||
### Prior proposals
|
||||
|
||||
There are a few prior proposals which tackle subsets of the above problem:
|
||||
|
||||
* [MSC1796](https://github.com/matrix-org/matrix-spec-proposals/pull/1796):
|
||||
similar to the proposal in this MSC, but limited to encrypted events (and kept
|
||||
in cleartext).
|
||||
* [MSC2463](https://github.com/matrix-org/matrix-spec-proposals/pull/2463):
|
||||
excludes searching inside a Matrix ID for localparts / display names of other
|
||||
users.
|
||||
* [MSC3517](https://github.com/matrix-org/matrix-spec-proposals/pull/3517):
|
||||
searches for Matrix IDs (instead of display name / localpart) and only searches
|
||||
specific event types & properties.
|
||||
* [Custom push rules](https://o.librepush.net/aux/matrix_reitools/pill_mention_rules.html)
|
||||
to search for matrix.to links instead of display name / localpart.
|
||||
|
||||
<details>
|
||||
|
||||
The above generates a new push rule to replace `.m.rule.contains_display_name`
|
||||
and `.m.rule.contains_user_name`:
|
||||
|
||||
```json
|
||||
{
|
||||
"conditions": [
|
||||
{
|
||||
"kind": "event_match",
|
||||
"key": "content.formatted_body",
|
||||
"pattern": "*https://matrix.to/#/@alice:example.org*"
|
||||
}
|
||||
],
|
||||
"actions" : [
|
||||
"notify",
|
||||
{
|
||||
"set_tweak": "sound",
|
||||
"value": "default"
|
||||
},
|
||||
{
|
||||
"set_tweak": "highlight"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
The last two proposals use a similar idea of attempting to find "pills" in the
|
||||
`formatted_body`, this has some downsides though:
|
||||
|
||||
* It doesn't allow for hidden mentions, which can be useful in some situations.
|
||||
* It does not work for event types other than `m.room.message`.
|
||||
|
||||
It also adds significant implementation complexity since the HTML messages must
|
||||
now be parsed for notifications. This is expensive and introduces potential
|
||||
security issues.
|
||||
|
||||
### Room version for backwards compatibility
|
||||
|
||||
Alternative backwards compatibility suggestions included using a new room version,
|
||||
similar to [MSC3932](https://github.com/matrix-org/matrix-spec-proposals/pull/3932)
|
||||
for extensible events. This does not seem like a good fit since room versions are
|
||||
not usually interested in non-state events. It would additionally require a stable
|
||||
room version before use, which would unnecessarily delay usage. Another MSC
|
||||
can address this concern, such as in the extensible events series, if
|
||||
desirable to be gated by a room version for a "clean slate" approach.
|
||||
|
||||
## Security considerations
|
||||
|
||||
None not already described.
|
||||
|
||||
## Unstable prefix
|
||||
|
||||
During development the following mapping will be used:
|
||||
|
||||
| What | Stable | Unstable |
|
||||
|---------------------|-------------------|--------------------------------------|
|
||||
| Event property | `m.mentions` | `org.matrix.msc3952.mentions` |
|
||||
| Push rule ID | `.m.rule.*` | `.org.matrix.msc3952.*` |
|
||||
|
||||
The server will include the `org.matrix.msc3952_intentional_mentions` flag in the
|
||||
`unstable_features` array of the `/versions` endpoint. If a client sees this flag
|
||||
it can choose to apply the deprecation logic discussed in the
|
||||
[backwards compatibility](#backwards-compatibility) section.
|
||||
|
||||
## Dependencies
|
||||
|
||||
This depends on the following (accepted) MSCs:
|
||||
|
||||
* [MSC3758](https://github.com/matrix-org/matrix-spec-proposals/pull/3758): Add `event_property_is` push rule condition kind
|
||||
* [MSC3873](https://github.com/matrix-org/matrix-spec-proposals/pull/3873): event_match dotted keys
|
||||
* [MSC3966](https://github.com/matrix-org/matrix-spec-proposals/pull/3966): `event_property_contains` push rule condition
|
||||
|
||||
<!-- Footnotes below: -->
|
||||
|
||||
[^1]: It is [defined as](https://spec.matrix.org/v1.5/client-server-api/#mroommessage-msgtypes)
|
||||
the the "plain text version of the HTML [`formatted_body`] should be provided in the `body`",
|
||||
but there is no particular algorithm to convert from HTML to plain text *except*
|
||||
when converting mentions, where the
|
||||
[plain text version uses the link anchor, not the link](https://spec.matrix.org/v1.5/client-server-api/#client-behaviour-26).
|
||||
|
||||
[^2]: As proposed in [issue 353](https://github.com/matrix-org/matrix-spec/issues/353).
|
||||
|
||||
[^3]: Note that this isn't really a change in behavior, it is just making the behavior
|
||||
explicit. It is expected that users already considered "pilled" users to be mentions,
|
||||
and it was more unexpected when non-pilled users *were* mentioned. This MSC fixes the
|
||||
latter case.
|
||||
|
||||
[^4]: Some protocols which provide structured data for mentions include
|
||||
[Twitter](https://developer.twitter.com/en/docs/twitter-api/data-dictionary/object-model/tweet),
|
||||
[Mastodon](https://docs.joinmastodon.org/entities/Status/#Mention),
|
||||
[Discord](https://discord.com/developers/docs/resources/channel#message-object),
|
||||
and [Microsoft Teams](https://learn.microsoft.com/en-us/graph/api/resources/chatmessagemention?view=graph-rest-1.0).
|
||||
|
||||
[^5]: Unfortunately some protocols do *not* provide structured data: the message
|
||||
itself must be parsed for mentions, e.g. IRC or
|
||||
[Slack](https://api.slack.com/reference/surfaces/formatting#mentioning-users).
|
Loading…
Reference in New Issue