From 511820d7629d03871491ddecfb5332276d8a48a8 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:15:54 +0000 Subject: [PATCH 01/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 223 +++++++++++++++++++++++++++++ 1 file changed, 223 insertions(+) create mode 100644 proposals/4295-bot-bounce-limit.md diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md new file mode 100644 index 00000000000..513262f7838 --- /dev/null +++ b/proposals/4295-bot-bounce-limit.md @@ -0,0 +1,223 @@ +# MSC4295: Bot bounce limit - a better loop prevention mechanism + +## Background + +Matrix is an open platform that welcomes bots and bridges. Unlike other platforms (e.g., Telegram), Matrix allows multiple bots to interact with each other, creating a unique and useful experience. However, this feature is a double-edged sword due to the risk of infinite loops between bots. A bot loop can cause an exponentially growing flood, damaging the reputation of the source homeserver and potentially leading to unintentional or intentional Denial-of-Service attacks. + +Here are some examples of multi-bot interactions and their needs for loop prevention: + +1. The room operator can run a "CAPTCHA bot" that screens every new member joining the room, but doesn't want these CAPTCHAs to be bridged to other platforms. [[1]](https://github.com/mautrix/telegram/issues/918) +2. The room operator can run a "GitHub CI bot" that reports CI task reports, and another "URL previewer bot" that generates URL previews from the former bot's output. (It is a separate debate whether a central-managed URL previewer bot is more privacy-preserving than the URL preview feature provided by each member's homeserver.) +3. For a room purposed for technical support, the operator can run an AI-powered bot to automatically answer common questions. Such AI bot is allowed to trigger other bots for certain helpful tasks. +4. The room operator can run a "UTD notification bot" that notifies room members that their messages can't be decrypted by others. However, it is very important to prevent it from replying another bot's message. +5. When bridging rooms across three or more platforms (e.g., Matrix ⇌ Telegram ⇌ IRC ⇌ Matrix), it is necessary to make sure each bridge doesn't pick up another bridge's messages. +6. Bridges supporting double-puppeting needs to ignore messages sent by a reverse puppet. Although they already employ proprietary methods (e.g., vendor-prefixed tags like `fi.mau.double_puppet_source` or a list of ignored user IDs), it could be very useful to provide a standardized loop-preventing mechanism, allowing bridges from different vendors to work in harmony at the same room. +Currently, it is usually a room operator's responsibility to prevent bot loops, for example, by carefully configuring each bot's ignore list, ensuring all possible outputs of one bot don't contain trigger words of another bot, and removing unauthorized bots invited by some random member. Nonetheless, a well-maintained configuration can be very fragile, and the room operator may not be able to monitor the room at all times. + +The goal of of this proposal is to: + +1. Reduce the burden on room operators --- they still carry the responsibility to prevent loops, but less effort is needed. +2. Allow bot developers to follow a standardized guideline for their bots to not cause trouble in a multi-bot environment. +3. In the event of a bot loop due to misconfiguration, ensure "specification-compliant" bots will eventually stop, giving the room operator time to react. +4. In rooms with no moderators, or even no human presence, reduce the risk that remaining bots generate an infinite amount of traffic without being noticed. +5. Promote a healthier Matrix ecosystem where multiple bots can collaborate better. +6. Be compatible with the existing `m.notice` mechanism. + +The goal of this proposal is **NOT** to: +1. Prevent any malicious bot from flooding a room. +2. Prevent a bot loop from happening at all. +3. Prevent a bot loop if the bot isn't yet updated to support this new proposal. + +## Existing solutions + +There are three existing solutions to prevent bot loops: + +1. The `m.notice` message type: + + By specification, `m.notice` messages must never be automatically responded to. + + However, there are a few disadvantages of `m.notice`: + + 1. It is analogous to `m.text`, which doesn't support attached files or encrypted images. + 2. It is designed for automated messages, not bridged messages sent originally by a human. + 3. Similarly, `m.notice` won't be picked up by bridges to forward to a bridged platform. + 4. It prevents multiple bots from collaborating. As shown above, bot collaborating can be helpful. + 5. It is difficult to decide whether an AI-powered bot should use `m.notice` or `m.text`. --- Should we give it ability to interact with other bots? + 6. `m.notice` is often displayed in a distinct manner, such as with a different text color, which, depending on the semantics of the message, may not always be ideal. + +2. A vendor-specific tags: + + For example, Mautrix attaches `fi.mau.double_puppet_source` tag to messages sent by a reverse puppet account. This tag is not visible to human, but can be inspected through "View JSON Source". Mautrix won't forward a message if the sender is a is a reverse puppet account managed by the same Mautrix instance and the message has such tag. [[2]](https://github.com/mautrix/python/blob/8eac9db01e2b5fd9a30620bcbc8ebbaa36c71ecb/mautrix/bridge/matrix.py#L960-L964) + + The downside of vendor-specific tags is obvious: One bot developer cannot expect all other bot developers to support their custom tag unless it's standardized. + +3. An ignore list: + + In the configuration file of a Matrix bot with such a feature, the operator can specify a list of users whose messages are ignored by the bot. + + However, a valid ignore list that allows multi-bot collaboration without bot loops is fragile. Adding new bots to the room, or adding new features to an existing bot, may lead to new bot loops. + + The new proposal won't replace ignore lists. Instead, it aims to complement them, enabling new creative use cases of Matrix bots. + +## Proposal: `m.bounce_limit` + +I propose a new tag `m.bounce_limit` inside the **unencrypted** `content` subobject of any message-like JSON objects, including `m.room.message`, `m.sticker`, and `m.room.encrypted`. (The debate on whether it should reside in the **encrypted** `content` will be discussed in the [Alternatives](#alternatives) section below.) + +A valid `m.bounce_limit` value can be in either of the following forms: + +1. Missing. +2. The number 1. +3. An integer between and including 2 and 2^53-1. + +These are invalid forms, and their normalization rules upon receiving: + +1. The number 0, which should be treated as missing. (This design is to simplify the development of bots in certain programming languages, such as Go.) +2. Any other values, including but not limited to negative numbers, decimal fractions, strings, etc., which should be treated as 1. + +Here are two example events: + +```json +{ + "content": { + "body": "It works!", + "m.bounce_limit": 3, + "m.mentions": {}, + "m.relates_to": { + "m.in_reply_to": { + "event_id": "$BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB" + } + }, + "msgtype": "m.notice", + }, + "sender": "@bot:example.com", + "type": "m.room.message", + "event_id": "$AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", + "room_id": "!AAAAAAAAAAAAAAAAAA:example.com" +} +``` + +```json +{ + "content": { + "algorithm": "m.megolm.v1.aes-sha2", + "ciphertext": "11Y45j14S19n19P81i0", + "device_id": "AAAAAAAAAA", + "m.bounce_limit": 3, + "m.relates_to": { + "m.in_reply_to": { + "event_id": "$BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB" + } + }, + "sender_key": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", + "session_id": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" + }, + "sender": "@bot:example.com", + "type": "m.room.encrypted", + "event_id": "$AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", + "room_id": "!AAAAAAAAAAAAAAAAAA:example.com" +} +``` + +The behavior of a client: + +1. If a message is sent by a human, `m.bounce_limit` is RECOMMENDED to be missing. In the case when the definition of "sent by a human" is ambiguous in certain applications, a message is considered equivalently "sent by a human" only if there is absolutely no risk of bot loops except for software malfunctions. In other words, bridged messages MUST NOT be considered "sent by human." +2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value. It MUST be an integer between and including 1 and 2^53-1. We RECOMMENDED that a bot allows its operator to configure the `max_outgoing_bounce_limit` to suit their needs. +3. A bot is allowed to process any incoming messages, but MUST NOT send response messages (including stickers) to any incoming messages: + 1. with an `m.bounce_limit` of 1 after normalization, or + 2. whose `m.bounce_limit` is missing after normalization AND with a `msgtype` of `m.notice`, or + 3. whose `m.bounce_limit` is missing after normalization AND the bot is unable to decrypt the message. +4. When the bot sends a response message (including stickers), it MUST set its outgoing `m.bounce_limit` to `min(incoming_bounce_limit - 1, max_outgoing_bounce_limit)`, where `incoming_bounce_limit` is the `m.bounce_limit` value of the incoming message, or `max_outgoing_bounce_limit` if the `m.bounce_limit` value of the incoming message is missing. +5. When a bot sends an outgoing message (including stickers) that is not a response to any incoming message, it MUST set its outgoing `m.bounce_limit` to `max_outgoing_bounce_limit`. +6. The bot SHOULD use `m.notice` unless there is a reason not to. Examples of valid reasons are listed in the [Existing solutions](#existing-solutions) section. +7. If the sole purpose of an SDK or library is to develop bots, and if it is convenient to do so, it SHOULD make `m.bounce_limit` support on by default. + +Compatibility advantages of this design: + +1. Most clients don't need to be aware of `m.bounce_limit`, thus requiring no modifications. +2. The semantics of `m.notice` is preserved. + +## Potential issues + +There are a few issues to consider: + +1. If the response of a bot is relevant to multiple incoming messages, it is not defined which message determines `incoming_bounce_limit`. + + Potential definitions could be the minimum value, the maximum value, or the last message's value. The bot developer also needs to pay special attention if some, but not all, of the relevant incoming messages have an `m.bounce_limit` of 1. + +2. If the response of a bot is not a message (or a sticker), the behavior is not defined. + + For example, if the bot's job is to change the room name, room topic, or pinned messages, this proposal does not define its behavior of loop prevention. + + Two bots racing with each other changing room states surely causes a bigger havoc, but we can't analyze it unless we observe a real problem. + +3. How `m.bounce_limit` propagates across bridges is undefined. + + Some platforms, such as Telegram, already prevents bot loops by forbidding bots from seeing each other's messages. + + Some other platforms, such as IRC, has bot loops as a long-standing problem. We don't aim to solve other people's problems. + + If a platform has a similar bounce limit mechanism, the bridge developer SHOULD try to pass the value across the bridge. + + Or, if a platform has an equivalent of `m.notice`, the bridge developer SHOULD try to map messages with `m.bounce_limit` of 2 to the `m.notice` equivalent of that platform. + +4. A probable implementation pitfall of unconditionally ignoring messages of `m.bounce_limit` of 1. + + If a bot's job is to prevent flooding or remove spam messages, it MUST NOT ignore messages based on their `m.bounce_limit` values. + + If the incoming relevant message has an `m.bounce_limit` of 1, the bot developer MUST judge wisely whether to let the bot perform its work quietly, but MUST NOT allow the bot to respond with a message. + +## Alternatives + +There are two alternative considerations: + +1. Whether to put `m.bounce_limit` into the **encrypted** `content`. + + Regarding this question, here are my reasons: + + 1. `sender` and `m.relates_to` are unencrypted. The information that can be inferred from `m.bounce_limit` is the same as what can be inferred from analyzing `sender` and `m.relates_to`. + 2. `m.bounce_limit` is similar to TTL in IPv4 or hop_limit in IPv6, which are unencrypted. + 3. The occurrence of bot loops does not require messages to be decrypted successfully. + 4. Putting `m.bounce_limit` in the cleartext allows a useful application of "UTD notification bot", described in the [Background](#background) section. + + In my personal experience, I set all my rooms to end-to-end encrypted. Such a "UTD notification bot" reduces the friction of this switch, as members can be notified of a potentially misconfigured client or an E2EE-incompatible homeserver almost immediately. My room members were skeptical before the E2EE switch but became satisfied afterward. By allowing more large-scale rooms to be encrypted, I believe the overall privacy of the Matrix ecosystem increases. + + However, the design of `m.bounce_limit` being in the cleartext relies on the fact that `m.bounce_limit` does not leak new information other than what can be inferred from `sender` and `m.relates_to`. Feel free to comment your opinions if I missed anything! + +2. Whether to introduce a structure for data exchange between bots, for example `m.bot_data_exchange`, and make `bounce_limit` a part of it. + + Regarding this question, here are my reasons: + + 1. It is impossible to standardize `m.bot_data_exange`, because it has to be flexible enough to accept any valid JSON. Vendor-prefixed tags should be a better choice for inter-bot data exchange. + 2. Obviously, `m.bot_data_exchange` has to be encrypted, while I propose that the bounce limit be unencrypted. + +3. Whether we should simply ban the usage of inter-bot interaction. + + As Matrix is an open platform, this is impossible. Additionally, the ability to perform bot-to-bot interaction sets Matrix bot apart from bots on other platforms, such as Telegram bots. + + Inter-bot interaction even enables some creative use cases, for example, allowing bots that primarily serve users on other platforms to use a bot-only Matrix rooms as an out-of-band communication channel. + +## Security considerations + +1. Denial-of-Service + + Bot loops can cause intentional or unintentional denial-of-service attacks. If two bots, one supports `m.bounce_limit` and the other doesn't, there could be a risk of causing bot loops, which leads to a denial-of-service. However, the severity is not worse than before. A room operator's typical responsiblity of keeping an eye on the bots hasn't changed, therefore, the room operator should be aware which bots don't support `m.bounce_limit` and configure accordingly. + +2. Information leakage from the cleartext `m.bounce_limit`. + + This is discussed in the [Alternatives](#alternatives) section. + +3. Bypassing room moderation bots due to implementation pitfalls. + + This is discussed in the [Potential issues](#potential-issues) section. + +## Unstable prefix + +When implementing this proposal, the unstable tag `io.github.m13253.bounce_limit` MUST be used. + +| Proposed stable tag name | Unstable tag name | +|--------------------------|---------------------------------| +| `m.bounce_limit` | `io.github.m13253.bounce_limit` | + +## Dependencies + +This MSC does not depend on any MSCs that are yet to be accepted. From c9d698b2cd899626bfeb20304b7768a0e3304b86 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:26:14 +0000 Subject: [PATCH 02/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 513262f7838..43ed519d67e 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -218,6 +218,12 @@ When implementing this proposal, the unstable tag `io.github.m13253.bounce_limit |--------------------------|---------------------------------| | `m.bounce_limit` | `io.github.m13253.bounce_limit` | +## Unstable Implementations + +This proposal requires no client modification. + +However, SDKs, bots, or bot frameworks can implement an unstable version of the proposal prior to its official acceptance. + ## Dependencies -This MSC does not depend on any MSCs that are yet to be accepted. +This MSC does not depend on any other MSCs that are yet to be accepted. From 738e4a8d3f74a6109a2f7234d43a50e4a5bb04b8 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:27:38 +0000 Subject: [PATCH 03/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 43ed519d67e..2a5201037da 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -200,7 +200,7 @@ There are two alternative considerations: 1. Denial-of-Service - Bot loops can cause intentional or unintentional denial-of-service attacks. If two bots, one supports `m.bounce_limit` and the other doesn't, there could be a risk of causing bot loops, which leads to a denial-of-service. However, the severity is not worse than before. A room operator's typical responsiblity of keeping an eye on the bots hasn't changed, therefore, the room operator should be aware which bots don't support `m.bounce_limit` and configure accordingly. + Bot loops can cause intentional or unintentional Denial-of-Service attacks. If two bots, one supports `m.bounce_limit` and the other doesn't, there could be a risk of causing bot loops, which leads to a Denial-of-Service. However, the severity is not worse than before. A room operator's typical responsiblity of keeping an eye on the bots hasn't changed, therefore, the room operator should be aware which bots don't support `m.bounce_limit` and configure accordingly. 2. Information leakage from the cleartext `m.bounce_limit`. From 01b72b8b19fac46cdeb968b69690ec8d656843c4 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:30:46 +0000 Subject: [PATCH 04/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 2a5201037da..2ce19b26ca4 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -12,6 +12,7 @@ Here are some examples of multi-bot interactions and their needs for loop preven 4. The room operator can run a "UTD notification bot" that notifies room members that their messages can't be decrypted by others. However, it is very important to prevent it from replying another bot's message. 5. When bridging rooms across three or more platforms (e.g., Matrix ⇌ Telegram ⇌ IRC ⇌ Matrix), it is necessary to make sure each bridge doesn't pick up another bridge's messages. 6. Bridges supporting double-puppeting needs to ignore messages sent by a reverse puppet. Although they already employ proprietary methods (e.g., vendor-prefixed tags like `fi.mau.double_puppet_source` or a list of ignored user IDs), it could be very useful to provide a standardized loop-preventing mechanism, allowing bridges from different vendors to work in harmony at the same room. + Currently, it is usually a room operator's responsibility to prevent bot loops, for example, by carefully configuring each bot's ignore list, ensuring all possible outputs of one bot don't contain trigger words of another bot, and removing unauthorized bots invited by some random member. Nonetheless, a well-maintained configuration can be very fragile, and the room operator may not be able to monitor the room at all times. The goal of of this proposal is to: From 21a88a70785bf2ef512932539ef295919ee46dc3 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:37:02 +0000 Subject: [PATCH 05/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 2ce19b26ca4..45bed6dfb47 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -122,7 +122,7 @@ Here are two example events: The behavior of a client: 1. If a message is sent by a human, `m.bounce_limit` is RECOMMENDED to be missing. In the case when the definition of "sent by a human" is ambiguous in certain applications, a message is considered equivalently "sent by a human" only if there is absolutely no risk of bot loops except for software malfunctions. In other words, bridged messages MUST NOT be considered "sent by human." -2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value. It MUST be an integer between and including 1 and 2^53-1. We RECOMMENDED that a bot allows its operator to configure the `max_outgoing_bounce_limit` to suit their needs. +2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value. It MUST be an integer between and including 1 and 2^53-1. We RECOMMENDED that a bot allows its operator to configure the `max_outgoing_bounce_limit` to suit their needs. We also RECOMMEND `max_outgoing_bounce_limit` defaults to be between and including 1 and 3, depending on the bot's job. 3. A bot is allowed to process any incoming messages, but MUST NOT send response messages (including stickers) to any incoming messages: 1. with an `m.bounce_limit` of 1 after normalization, or 2. whose `m.bounce_limit` is missing after normalization AND with a `msgtype` of `m.notice`, or From 7d5cb6e0071f31e335f9614c3fde01dbb0e60c1a Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:38:44 +0000 Subject: [PATCH 06/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 45bed6dfb47..a703917c682 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -122,7 +122,10 @@ Here are two example events: The behavior of a client: 1. If a message is sent by a human, `m.bounce_limit` is RECOMMENDED to be missing. In the case when the definition of "sent by a human" is ambiguous in certain applications, a message is considered equivalently "sent by a human" only if there is absolutely no risk of bot loops except for software malfunctions. In other words, bridged messages MUST NOT be considered "sent by human." -2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value. It MUST be an integer between and including 1 and 2^53-1. We RECOMMENDED that a bot allows its operator to configure the `max_outgoing_bounce_limit` to suit their needs. We also RECOMMEND `max_outgoing_bounce_limit` defaults to be between and including 1 and 3, depending on the bot's job. +2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value. + 1. It MUST be an integer between and including 1 and 2^53-1. + 2. We RECOMMENDED that a bot allows its operator to configure the `max_outgoing_bounce_limit` to suit their needs. + 3. We also RECOMMEND `max_outgoing_bounce_limit` defaults to be between and including 1 and 3, depending on the bot's job. 3. A bot is allowed to process any incoming messages, but MUST NOT send response messages (including stickers) to any incoming messages: 1. with an `m.bounce_limit` of 1 after normalization, or 2. whose `m.bounce_limit` is missing after normalization AND with a `msgtype` of `m.notice`, or From 3c24ec1f05d309a28365eab3ffd541a86a6a31f4 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:39:51 +0000 Subject: [PATCH 07/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index a703917c682..8e05891df42 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -122,7 +122,7 @@ Here are two example events: The behavior of a client: 1. If a message is sent by a human, `m.bounce_limit` is RECOMMENDED to be missing. In the case when the definition of "sent by a human" is ambiguous in certain applications, a message is considered equivalently "sent by a human" only if there is absolutely no risk of bot loops except for software malfunctions. In other words, bridged messages MUST NOT be considered "sent by human." -2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value. +2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value, which does not need to be shared. 1. It MUST be an integer between and including 1 and 2^53-1. 2. We RECOMMENDED that a bot allows its operator to configure the `max_outgoing_bounce_limit` to suit their needs. 3. We also RECOMMEND `max_outgoing_bounce_limit` defaults to be between and including 1 and 3, depending on the bot's job. From 90d512ef2d6588b28fd028dac8cfd60ba18450bb Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:49:33 +0000 Subject: [PATCH 08/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 8e05891df42..48a1e4880a2 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -72,7 +72,7 @@ A valid `m.bounce_limit` value can be in either of the following forms: These are invalid forms, and their normalization rules upon receiving: -1. The number 0, which should be treated as missing. (This design is to simplify the development of bots in certain programming languages, such as Go.) +1. The number ±0, which should be treated as missing. (This design is to simplify the development of bots in certain programming languages, such as Go.) 2. Any other values, including but not limited to negative numbers, decimal fractions, strings, etc., which should be treated as 1. Here are two example events: From 24f2cdd95f06bd53557435b44c48b6466e230d28 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:56:13 +0000 Subject: [PATCH 09/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 48a1e4880a2..f8756f66a86 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -72,8 +72,9 @@ A valid `m.bounce_limit` value can be in either of the following forms: These are invalid forms, and their normalization rules upon receiving: -1. The number ±0, which should be treated as missing. (This design is to simplify the development of bots in certain programming languages, such as Go.) -2. Any other values, including but not limited to negative numbers, decimal fractions, strings, etc., which should be treated as 1. +1. The number 0, which should be treated as missing. (This design is to simplify the development of bots in certain programming languages, such as Go.) +2. Floating-point numbers are not permitted by Matrix protocol. +3. Any other values, including but not limited to negative numbers, strings, etc., which should be treated as the number 1. Here are two example events: From dc534f203f4bfa8824fb8580de879ad826defae6 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:58:30 +0000 Subject: [PATCH 10/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index f8756f66a86..968862172da 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -6,7 +6,7 @@ Matrix is an open platform that welcomes bots and bridges. Unlike other platform Here are some examples of multi-bot interactions and their needs for loop prevention: -1. The room operator can run a "CAPTCHA bot" that screens every new member joining the room, but doesn't want these CAPTCHAs to be bridged to other platforms. [[1]](https://github.com/mautrix/telegram/issues/918) +1. The room operator can run a "CAPTCHA bot" that screens every new member joining the room, but doesn't want these CAPTCHAs to be bridged to other platforms [[1]](https://github.com/mautrix/telegram/issues/918). 2. The room operator can run a "GitHub CI bot" that reports CI task reports, and another "URL previewer bot" that generates URL previews from the former bot's output. (It is a separate debate whether a central-managed URL previewer bot is more privacy-preserving than the URL preview feature provided by each member's homeserver.) 3. For a room purposed for technical support, the operator can run an AI-powered bot to automatically answer common questions. Such AI bot is allowed to trigger other bots for certain helpful tasks. 4. The room operator can run a "UTD notification bot" that notifies room members that their messages can't be decrypted by others. However, it is very important to prevent it from replying another bot's message. @@ -46,9 +46,9 @@ There are three existing solutions to prevent bot loops: 5. It is difficult to decide whether an AI-powered bot should use `m.notice` or `m.text`. --- Should we give it ability to interact with other bots? 6. `m.notice` is often displayed in a distinct manner, such as with a different text color, which, depending on the semantics of the message, may not always be ideal. -2. A vendor-specific tags: +2. Vendor-specific tags: - For example, Mautrix attaches `fi.mau.double_puppet_source` tag to messages sent by a reverse puppet account. This tag is not visible to human, but can be inspected through "View JSON Source". Mautrix won't forward a message if the sender is a is a reverse puppet account managed by the same Mautrix instance and the message has such tag. [[2]](https://github.com/mautrix/python/blob/8eac9db01e2b5fd9a30620bcbc8ebbaa36c71ecb/mautrix/bridge/matrix.py#L960-L964) + For example, Mautrix attaches `fi.mau.double_puppet_source` tag to messages sent by a reverse puppet account. This tag is not visible to human, but can be inspected through "View JSON Source." Mautrix won't forward a message if the sender is a is a reverse puppet account managed by the same Mautrix instance and the message has such tag [[2]](https://github.com/mautrix/python/blob/8eac9db01e2b5fd9a30620bcbc8ebbaa36c71ecb/mautrix/bridge/matrix.py#L960-L964). The downside of vendor-specific tags is obvious: One bot developer cannot expect all other bot developers to support their custom tag unless it's standardized. @@ -182,7 +182,7 @@ There are two alternative considerations: 1. `sender` and `m.relates_to` are unencrypted. The information that can be inferred from `m.bounce_limit` is the same as what can be inferred from analyzing `sender` and `m.relates_to`. 2. `m.bounce_limit` is similar to TTL in IPv4 or hop_limit in IPv6, which are unencrypted. 3. The occurrence of bot loops does not require messages to be decrypted successfully. - 4. Putting `m.bounce_limit` in the cleartext allows a useful application of "UTD notification bot", described in the [Background](#background) section. + 4. Putting `m.bounce_limit` in the cleartext allows a useful application of "UTD notification bot," described in the [Background](#background) section. In my personal experience, I set all my rooms to end-to-end encrypted. Such a "UTD notification bot" reduces the friction of this switch, as members can be notified of a potentially misconfigured client or an E2EE-incompatible homeserver almost immediately. My room members were skeptical before the E2EE switch but became satisfied afterward. By allowing more large-scale rooms to be encrypted, I believe the overall privacy of the Matrix ecosystem increases. From ceb0e8b329eb292cc07310350e6e143c37b5c610 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 03:59:47 +0000 Subject: [PATCH 11/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 968862172da..6af03e8220b 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -7,7 +7,7 @@ Matrix is an open platform that welcomes bots and bridges. Unlike other platform Here are some examples of multi-bot interactions and their needs for loop prevention: 1. The room operator can run a "CAPTCHA bot" that screens every new member joining the room, but doesn't want these CAPTCHAs to be bridged to other platforms [[1]](https://github.com/mautrix/telegram/issues/918). -2. The room operator can run a "GitHub CI bot" that reports CI task reports, and another "URL previewer bot" that generates URL previews from the former bot's output. (It is a separate debate whether a central-managed URL previewer bot is more privacy-preserving than the URL preview feature provided by each member's homeserver.) +2. The room operator can run a "GitHub CI bot" that sends CI task reports, and another "URL previewer bot" that generates URL previews from the former bot's output. (It is a separate debate whether a central-managed URL previewer bot is more privacy-preserving than the URL preview feature provided by each member's homeserver.) 3. For a room purposed for technical support, the operator can run an AI-powered bot to automatically answer common questions. Such AI bot is allowed to trigger other bots for certain helpful tasks. 4. The room operator can run a "UTD notification bot" that notifies room members that their messages can't be decrypted by others. However, it is very important to prevent it from replying another bot's message. 5. When bridging rooms across three or more platforms (e.g., Matrix ⇌ Telegram ⇌ IRC ⇌ Matrix), it is necessary to make sure each bridge doesn't pick up another bridge's messages. From b85d576de021c2a4b9b7cf1482667647355eeade Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 04:12:35 +0000 Subject: [PATCH 12/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 6af03e8220b..737e55591b7 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -126,7 +126,7 @@ The behavior of a client: 2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value, which does not need to be shared. 1. It MUST be an integer between and including 1 and 2^53-1. 2. We RECOMMENDED that a bot allows its operator to configure the `max_outgoing_bounce_limit` to suit their needs. - 3. We also RECOMMEND `max_outgoing_bounce_limit` defaults to be between and including 1 and 3, depending on the bot's job. + 3. We also RECOMMEND `max_outgoing_bounce_limit` defaults to be 1, or with a valid reason (e.g., due to the bot's job), no more 3. 3. A bot is allowed to process any incoming messages, but MUST NOT send response messages (including stickers) to any incoming messages: 1. with an `m.bounce_limit` of 1 after normalization, or 2. whose `m.bounce_limit` is missing after normalization AND with a `msgtype` of `m.notice`, or From 811d761c9cb51314ca208629906b4e2378c3f092 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 04:15:25 +0000 Subject: [PATCH 13/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 737e55591b7..6815b6f1167 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -161,7 +161,7 @@ There are a few issues to consider: Some other platforms, such as IRC, has bot loops as a long-standing problem. We don't aim to solve other people's problems. - If a platform has a similar bounce limit mechanism, the bridge developer SHOULD try to pass the value across the bridge. + If a platform has a similar bounce limit mechanism, the bridge developer SHOULD try to pass `m.bounce_limit - 1` across the bridge. Or, if a platform has an equivalent of `m.notice`, the bridge developer SHOULD try to map messages with `m.bounce_limit` of 2 to the `m.notice` equivalent of that platform. From 7da2a0e3add10d1b096975441a4e0e6a0df58321 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 04:24:57 +0000 Subject: [PATCH 14/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 6815b6f1167..8801d18df35 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -133,8 +133,9 @@ The behavior of a client: 3. whose `m.bounce_limit` is missing after normalization AND the bot is unable to decrypt the message. 4. When the bot sends a response message (including stickers), it MUST set its outgoing `m.bounce_limit` to `min(incoming_bounce_limit - 1, max_outgoing_bounce_limit)`, where `incoming_bounce_limit` is the `m.bounce_limit` value of the incoming message, or `max_outgoing_bounce_limit` if the `m.bounce_limit` value of the incoming message is missing. 5. When a bot sends an outgoing message (including stickers) that is not a response to any incoming message, it MUST set its outgoing `m.bounce_limit` to `max_outgoing_bounce_limit`. -6. The bot SHOULD use `m.notice` unless there is a reason not to. Examples of valid reasons are listed in the [Existing solutions](#existing-solutions) section. -7. If the sole purpose of an SDK or library is to develop bots, and if it is convenient to do so, it SHOULD make `m.bounce_limit` support on by default. +6. The bot SHOULD use `m.notice` unless there is a reason not to. Examples of such reasons are listed in the [Existing solutions](#existing-solutions) section. +7. Bridges consume one bounce similar to bots. In other words, if a message MUST NOT be responded by a bot, it MUST NOT be forwarded by a bridge either. +8. If the sole purpose of an SDK or library is to develop bots or bridges, and if it is convenient to do so, it SHOULD make `m.bounce_limit` support on by default. Compatibility advantages of this design: From a90a2a7795378e539a4653ec7e25d13e018c3559 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 04:27:07 +0000 Subject: [PATCH 15/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 8801d18df35..9712977005b 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -162,7 +162,7 @@ There are a few issues to consider: Some other platforms, such as IRC, has bot loops as a long-standing problem. We don't aim to solve other people's problems. - If a platform has a similar bounce limit mechanism, the bridge developer SHOULD try to pass `m.bounce_limit - 1` across the bridge. + If a platform has a similar bounce limit mechanism, the bridge developer SHOULD try to pass the bounce limit value across the bridge as `m.bounce_limit - 1`. Or, if a platform has an equivalent of `m.notice`, the bridge developer SHOULD try to map messages with `m.bounce_limit` of 2 to the `m.notice` equivalent of that platform. From 017df9fca672e74909ae89c38c6f24e07503b53c Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 04:32:24 +0000 Subject: [PATCH 16/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 9712977005b..4067b0c0efb 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -181,7 +181,7 @@ There are two alternative considerations: Regarding this question, here are my reasons: 1. `sender` and `m.relates_to` are unencrypted. The information that can be inferred from `m.bounce_limit` is the same as what can be inferred from analyzing `sender` and `m.relates_to`. - 2. `m.bounce_limit` is similar to TTL in IPv4 or hop_limit in IPv6, which are unencrypted. + 2. `m.bounce_limit` is similar to TTL in IPv4 or hop_limit in IPv6, which are unencrypted even under IPsec encryption. 3. The occurrence of bot loops does not require messages to be decrypted successfully. 4. Putting `m.bounce_limit` in the cleartext allows a useful application of "UTD notification bot," described in the [Background](#background) section. From 7b09272b5df5caff056bd90bf32ff9ce179609c1 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 04:33:20 +0000 Subject: [PATCH 17/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 4067b0c0efb..e25ace9e5db 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -181,7 +181,7 @@ There are two alternative considerations: Regarding this question, here are my reasons: 1. `sender` and `m.relates_to` are unencrypted. The information that can be inferred from `m.bounce_limit` is the same as what can be inferred from analyzing `sender` and `m.relates_to`. - 2. `m.bounce_limit` is similar to TTL in IPv4 or hop_limit in IPv6, which are unencrypted even under IPsec encryption. + 2. `m.bounce_limit` is similar to TTL in IPv4 or Hop Limit in IPv6, which are unencrypted even under IPsec encryption. 3. The occurrence of bot loops does not require messages to be decrypted successfully. 4. Putting `m.bounce_limit` in the cleartext allows a useful application of "UTD notification bot," described in the [Background](#background) section. From e6bf13c0931e5873b2bc4c80e1960ebad7bd01da Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 04:36:12 +0000 Subject: [PATCH 18/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index e25ace9e5db..42d3d9e3627 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -200,7 +200,7 @@ There are two alternative considerations: As Matrix is an open platform, this is impossible. Additionally, the ability to perform bot-to-bot interaction sets Matrix bot apart from bots on other platforms, such as Telegram bots. - Inter-bot interaction even enables some creative use cases, for example, allowing bots that primarily serve users on other platforms to use a bot-only Matrix rooms as an out-of-band communication channel. + Inter-bot interaction even enables some creative use cases, for example, allowing bots that primarily serve users on other platforms to use a bot-only Matrix room as an out-of-band communication channel. ## Security considerations From dfb59f656247bda306e4be5c2081676ba02f97fe Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 04:48:39 +0000 Subject: [PATCH 19/28] MSC4295: Bot bounce limit - a better loop prevention mechanism --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 42d3d9e3627..2909e3e9574 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -154,7 +154,7 @@ There are a few issues to consider: For example, if the bot's job is to change the room name, room topic, or pinned messages, this proposal does not define its behavior of loop prevention. - Two bots racing with each other changing room states surely causes a bigger havoc, but we can't analyze it unless we observe a real problem. + Two bots racing with each other changing room states surely causes a bigger havoc, but we can't analyze a fictional problem unless we observe it real. 3. How `m.bounce_limit` propagates across bridges is undefined. From 932a32c304fa1f30e063212b1c9cb8f2a7762d0d Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 11:11:51 +0000 Subject: [PATCH 20/28] MSC4295: Address review comments --- proposals/4295-bot-bounce-limit.md | 44 +++++++++++++++--------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 2909e3e9574..f4f93288b12 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -7,18 +7,18 @@ Matrix is an open platform that welcomes bots and bridges. Unlike other platform Here are some examples of multi-bot interactions and their needs for loop prevention: 1. The room operator can run a "CAPTCHA bot" that screens every new member joining the room, but doesn't want these CAPTCHAs to be bridged to other platforms [[1]](https://github.com/mautrix/telegram/issues/918). -2. The room operator can run a "GitHub CI bot" that sends CI task reports, and another "URL previewer bot" that generates URL previews from the former bot's output. (It is a separate debate whether a central-managed URL previewer bot is more privacy-preserving than the URL preview feature provided by each member's homeserver.) -3. For a room purposed for technical support, the operator can run an AI-powered bot to automatically answer common questions. Such AI bot is allowed to trigger other bots for certain helpful tasks. -4. The room operator can run a "UTD notification bot" that notifies room members that their messages can't be decrypted by others. However, it is very important to prevent it from replying another bot's message. +2. The room operator can run a "GitHub CI bot" that sends CI task reports, and another "URL previewer bot" that generates URL previews from the former bot's output. (It is a separate debate whether a centrally-managed URL previewer bot is more privacy-preserving than the URL preview feature provided by each member's homeserver.) +3. For a room purposed for technical support, the operator can run an AI-powered bot to automatically answer common questions. Such an AI bot is allowed to trigger other bots for certain helpful tasks. +4. The room operator can run a "UTD notification bot" that notifies room members that their messages can't be decrypted by others. However, it is very important to prevent it from replying to another bot's message. 5. When bridging rooms across three or more platforms (e.g., Matrix ⇌ Telegram ⇌ IRC ⇌ Matrix), it is necessary to make sure each bridge doesn't pick up another bridge's messages. -6. Bridges supporting double-puppeting needs to ignore messages sent by a reverse puppet. Although they already employ proprietary methods (e.g., vendor-prefixed tags like `fi.mau.double_puppet_source` or a list of ignored user IDs), it could be very useful to provide a standardized loop-preventing mechanism, allowing bridges from different vendors to work in harmony at the same room. +6. If the same bot provides native versions for multiple platforms, the room operator may want to let the bot itself provide native experiences on different platforms (e.g., `!bot help` on Matrix and IRC, `/help@bot` on Telegram, `/help` on Discord, etc.). This bot needs to bridge its outputs by itself to make command palettes work, thus it needs to inform any existing bridges to ignore its output to prevent double bridging. Currently, it is usually a room operator's responsibility to prevent bot loops, for example, by carefully configuring each bot's ignore list, ensuring all possible outputs of one bot don't contain trigger words of another bot, and removing unauthorized bots invited by some random member. Nonetheless, a well-maintained configuration can be very fragile, and the room operator may not be able to monitor the room at all times. -The goal of of this proposal is to: +The goal of this proposal is to: 1. Reduce the burden on room operators --- they still carry the responsibility to prevent loops, but less effort is needed. -2. Allow bot developers to follow a standardized guideline for their bots to not cause trouble in a multi-bot environment. +2. Allow bot developers to follow a standardized guideline for their bots not to cause trouble in a multi-bot environment. 3. In the event of a bot loop due to misconfiguration, ensure "specification-compliant" bots will eventually stop, giving the room operator time to react. 4. In rooms with no moderators, or even no human presence, reduce the risk that remaining bots generate an infinite amount of traffic without being noticed. 5. Promote a healthier Matrix ecosystem where multiple bots can collaborate better. @@ -41,14 +41,14 @@ There are three existing solutions to prevent bot loops: 1. It is analogous to `m.text`, which doesn't support attached files or encrypted images. 2. It is designed for automated messages, not bridged messages sent originally by a human. - 3. Similarly, `m.notice` won't be picked up by bridges to forward to a bridged platform. - 4. It prevents multiple bots from collaborating. As shown above, bot collaborating can be helpful. - 5. It is difficult to decide whether an AI-powered bot should use `m.notice` or `m.text`. --- Should we give it ability to interact with other bots? + 3. The current Matrix specification doesn't define whether bridges should forward `m.notice` to different platforms. + 4. It prevents multiple bots from collaborating. As shown above, bot collaboration can be helpful. + 5. It is difficult to decide whether an AI-powered bot should use `m.notice` or `m.text`. --- Should we give it the ability to interact with other bots? 6. `m.notice` is often displayed in a distinct manner, such as with a different text color, which, depending on the semantics of the message, may not always be ideal. 2. Vendor-specific tags: - For example, Mautrix attaches `fi.mau.double_puppet_source` tag to messages sent by a reverse puppet account. This tag is not visible to human, but can be inspected through "View JSON Source." Mautrix won't forward a message if the sender is a is a reverse puppet account managed by the same Mautrix instance and the message has such tag [[2]](https://github.com/mautrix/python/blob/8eac9db01e2b5fd9a30620bcbc8ebbaa36c71ecb/mautrix/bridge/matrix.py#L960-L964). + For example, Mautrix attaches the `fi.mau.double_puppet_source` tag to messages sent by a reverse puppet account. This tag is not visible to humans, but can be inspected through "View JSON Source." Mautrix won't forward a message if the sender is a reverse puppet account managed by the same Mautrix instance and the message has such a tag [[2]](https://github.com/mautrix/python/blob/8eac9db01e2b5fd9a30620bcbc8ebbaa36c71ecb/mautrix/bridge/matrix.py#L960-L964). The downside of vendor-specific tags is obvious: One bot developer cannot expect all other bot developers to support their custom tag unless it's standardized. @@ -73,7 +73,7 @@ A valid `m.bounce_limit` value can be in either of the following forms: These are invalid forms, and their normalization rules upon receiving: 1. The number 0, which should be treated as missing. (This design is to simplify the development of bots in certain programming languages, such as Go.) -2. Floating-point numbers are not permitted by Matrix protocol. +2. Floating-point numbers are not permitted by the Matrix protocol. 3. Any other values, including but not limited to negative numbers, strings, etc., which should be treated as the number 1. Here are two example events: @@ -126,7 +126,7 @@ The behavior of a client: 2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value, which does not need to be shared. 1. It MUST be an integer between and including 1 and 2^53-1. 2. We RECOMMENDED that a bot allows its operator to configure the `max_outgoing_bounce_limit` to suit their needs. - 3. We also RECOMMEND `max_outgoing_bounce_limit` defaults to be 1, or with a valid reason (e.g., due to the bot's job), no more 3. + 3. We also RECOMMEND `max_outgoing_bounce_limit` default to 1, or with a valid reason (e.g., due to the bot's job), no more than 3. 3. A bot is allowed to process any incoming messages, but MUST NOT send response messages (including stickers) to any incoming messages: 1. with an `m.bounce_limit` of 1 after normalization, or 2. whose `m.bounce_limit` is missing after normalization AND with a `msgtype` of `m.notice`, or @@ -152,21 +152,21 @@ There are a few issues to consider: 2. If the response of a bot is not a message (or a sticker), the behavior is not defined. - For example, if the bot's job is to change the room name, room topic, or pinned messages, this proposal does not define its behavior of loop prevention. + For example, if the bot's job is to change the room name, room topic, or pinned messages, this proposal does not define its loop prevention behavior. - Two bots racing with each other changing room states surely causes a bigger havoc, but we can't analyze a fictional problem unless we observe it real. + Two bots racing with each other changing room states would surely cause greater havoc, but we can't analyze such a hypothetical problem until it is observed in practice. 3. How `m.bounce_limit` propagates across bridges is undefined. - Some platforms, such as Telegram, already prevents bot loops by forbidding bots from seeing each other's messages. + Some platforms, such as Telegram, already prevent bot loops by forbidding bots from seeing each other's messages. - Some other platforms, such as IRC, has bot loops as a long-standing problem. We don't aim to solve other people's problems. + Some other platforms, such as IRC, have bot loops as a long-standing problem. We don't aim to solve other people's problems. If a platform has a similar bounce limit mechanism, the bridge developer SHOULD try to pass the bounce limit value across the bridge as `m.bounce_limit - 1`. Or, if a platform has an equivalent of `m.notice`, the bridge developer SHOULD try to map messages with `m.bounce_limit` of 2 to the `m.notice` equivalent of that platform. -4. A probable implementation pitfall of unconditionally ignoring messages of `m.bounce_limit` of 1. +4. A probable implementation pitfall of unconditionally ignoring messages with an `m.bounce_limit` of 1. If a bot's job is to prevent flooding or remove spam messages, it MUST NOT ignore messages based on their `m.bounce_limit` values. @@ -174,7 +174,7 @@ There are a few issues to consider: ## Alternatives -There are two alternative considerations: +There are three alternative considerations: 1. Whether to put `m.bounce_limit` into the **encrypted** `content`. @@ -193,12 +193,12 @@ There are two alternative considerations: Regarding this question, here are my reasons: - 1. It is impossible to standardize `m.bot_data_exange`, because it has to be flexible enough to accept any valid JSON. Vendor-prefixed tags should be a better choice for inter-bot data exchange. + 1. It is impossible to standardize `m.bot_data_exchange`, because it has to be flexible enough to accept any valid JSON. Vendor-prefixed tags should be a better choice for inter-bot data exchange. 2. Obviously, `m.bot_data_exchange` has to be encrypted, while I propose that the bounce limit be unencrypted. -3. Whether we should simply ban the usage of inter-bot interaction. +3. Whether we should simply ban inter-bot interaction. - As Matrix is an open platform, this is impossible. Additionally, the ability to perform bot-to-bot interaction sets Matrix bot apart from bots on other platforms, such as Telegram bots. + As Matrix is an open platform, this is impossible. Additionally, the ability to perform bot-to-bot interaction sets Matrix bots apart from bots on other platforms, such as Telegram bots. Inter-bot interaction even enables some creative use cases, for example, allowing bots that primarily serve users on other platforms to use a bot-only Matrix room as an out-of-band communication channel. @@ -206,7 +206,7 @@ There are two alternative considerations: 1. Denial-of-Service - Bot loops can cause intentional or unintentional Denial-of-Service attacks. If two bots, one supports `m.bounce_limit` and the other doesn't, there could be a risk of causing bot loops, which leads to a Denial-of-Service. However, the severity is not worse than before. A room operator's typical responsiblity of keeping an eye on the bots hasn't changed, therefore, the room operator should be aware which bots don't support `m.bounce_limit` and configure accordingly. + Bot loops can cause intentional or unintentional Denial-of-Service attacks. If two bots, one supports `m.bounce_limit` and the other doesn't, there could be a risk of causing bot loops, which leads to a Denial-of-Service. However, the severity is not worse than before. A room operator's typical responsibility of keeping an eye on the bots hasn't changed, therefore, the room operator should be aware which bots don't support `m.bounce_limit` and configure accordingly. 2. Information leakage from the cleartext `m.bounce_limit`. From 1867a16a39f11638d1cf829a346f3aa5b1d9c924 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 11:16:17 +0000 Subject: [PATCH 21/28] MSC4295: Rewrite the section about vendor-specific tags --- proposals/4295-bot-bounce-limit.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index f4f93288b12..f6ca15d6fb0 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -50,7 +50,9 @@ There are three existing solutions to prevent bot loops: For example, Mautrix attaches the `fi.mau.double_puppet_source` tag to messages sent by a reverse puppet account. This tag is not visible to humans, but can be inspected through "View JSON Source." Mautrix won't forward a message if the sender is a reverse puppet account managed by the same Mautrix instance and the message has such a tag [[2]](https://github.com/mautrix/python/blob/8eac9db01e2b5fd9a30620bcbc8ebbaa36c71ecb/mautrix/bridge/matrix.py#L960-L964). - The downside of vendor-specific tags is obvious: One bot developer cannot expect all other bot developers to support their custom tag unless it's standardized. + There are two downsides of vendor-specific tags: + 1. One bot developer cannot expect all other bot developers to support their custom tag unless it's standardized. + 2. The purpose of some vendor-specific tags (e.g., `fi.mau.double_puppet_source`) may be intra-bot loop prevention, instead of inter-bot, thus serves a different purpose than this proposal. 3. An ignore list: From 6e606efd2bfef648ee6fa08cd4025757a2e743d1 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 11:19:50 +0000 Subject: [PATCH 22/28] MSC4295: Rewrite the section about vendor-specific tags --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index f6ca15d6fb0..86f46a31728 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -52,7 +52,7 @@ There are three existing solutions to prevent bot loops: There are two downsides of vendor-specific tags: 1. One bot developer cannot expect all other bot developers to support their custom tag unless it's standardized. - 2. The purpose of some vendor-specific tags (e.g., `fi.mau.double_puppet_source`) may be intra-bot loop prevention, instead of inter-bot, thus serves a different purpose than this proposal. + 2. Vendor-specific tags exist for a reason: they sometimes serve a different purpose than this proposal. For example, `fi.mau.double_puppet_source` prevents intra-bot loops, instead of inter-bot loops. 3. An ignore list: From 101581c7be8b523bbfe02ce3b0595832ca442634 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 11:24:37 +0000 Subject: [PATCH 23/28] MSC4295: Minor refines --- proposals/4295-bot-bounce-limit.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 86f46a31728..f836147f79c 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -17,7 +17,7 @@ Currently, it is usually a room operator's responsibility to prevent bot loops, The goal of this proposal is to: -1. Reduce the burden on room operators --- they still carry the responsibility to prevent loops, but less effort is needed. +1. Reduce the burden on room operators — they still carry the responsibility to prevent loops, but less effort is needed. 2. Allow bot developers to follow a standardized guideline for their bots not to cause trouble in a multi-bot environment. 3. In the event of a bot loop due to misconfiguration, ensure "specification-compliant" bots will eventually stop, giving the room operator time to react. 4. In rooms with no moderators, or even no human presence, reduce the risk that remaining bots generate an infinite amount of traffic without being noticed. @@ -43,7 +43,7 @@ There are three existing solutions to prevent bot loops: 2. It is designed for automated messages, not bridged messages sent originally by a human. 3. The current Matrix specification doesn't define whether bridges should forward `m.notice` to different platforms. 4. It prevents multiple bots from collaborating. As shown above, bot collaboration can be helpful. - 5. It is difficult to decide whether an AI-powered bot should use `m.notice` or `m.text`. --- Should we give it the ability to interact with other bots? + 5. It is difficult to decide whether an AI-powered bot should use `m.notice` or `m.text`. —Should we give it the ability to interact with other bots? 6. `m.notice` is often displayed in a distinct manner, such as with a different text color, which, depending on the semantics of the message, may not always be ideal. 2. Vendor-specific tags: @@ -52,7 +52,7 @@ There are three existing solutions to prevent bot loops: There are two downsides of vendor-specific tags: 1. One bot developer cannot expect all other bot developers to support their custom tag unless it's standardized. - 2. Vendor-specific tags exist for a reason: they sometimes serve a different purpose than this proposal. For example, `fi.mau.double_puppet_source` prevents intra-bot loops, instead of inter-bot loops. + 2. Vendor-specific tags exist for a reason: they sometimes serve a different purpose than this proposal. For example, `fi.mau.double_puppet_source` prevents intra-bot loops — double puppeting's unique challenge, instead of inter-bot loops. 3. An ignore list: From fe9cfb7af18298f5d0cbeafc54bfb18ec7ddc93e Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 11:25:14 +0000 Subject: [PATCH 24/28] MSC4295: Bot bounce limit - a better loop prevention mechanism Signed-off-by: Star Brilliant From 0c3ab5c4b2c3bbe6f9f9d4d013c915e69dab22ed Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 11:48:33 +0000 Subject: [PATCH 25/28] MSC4295: Minor rewording Signed-off-by: Star Brilliant --- proposals/4295-bot-bounce-limit.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index f836147f79c..a23974734ae 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -50,9 +50,10 @@ There are three existing solutions to prevent bot loops: For example, Mautrix attaches the `fi.mau.double_puppet_source` tag to messages sent by a reverse puppet account. This tag is not visible to humans, but can be inspected through "View JSON Source." Mautrix won't forward a message if the sender is a reverse puppet account managed by the same Mautrix instance and the message has such a tag [[2]](https://github.com/mautrix/python/blob/8eac9db01e2b5fd9a30620bcbc8ebbaa36c71ecb/mautrix/bridge/matrix.py#L960-L964). - There are two downsides of vendor-specific tags: + There are two concerns of vendor-specific tags: + 1. One bot developer cannot expect all other bot developers to support their custom tag unless it's standardized. - 2. Vendor-specific tags exist for a reason: they sometimes serve a different purpose than this proposal. For example, `fi.mau.double_puppet_source` prevents intra-bot loops — double puppeting's unique challenge, instead of inter-bot loops. + 2. Vendor-specific tags exist for a reason: they sometimes serve a different purpose than this proposal and can't replace each other. For example, `fi.mau.double_puppet_source` prevents intra-bot loops — double puppeting's unique challenge, instead of inter-bot loops. 3. An ignore list: @@ -60,7 +61,7 @@ There are three existing solutions to prevent bot loops: However, a valid ignore list that allows multi-bot collaboration without bot loops is fragile. Adding new bots to the room, or adding new features to an existing bot, may lead to new bot loops. - The new proposal won't replace ignore lists. Instead, it aims to complement them, enabling new creative use cases of Matrix bots. + The new proposal won't replace ignore lists. Instead, it aims to complement the mechanism, enabling new creative use cases of Matrix bots. ## Proposal: `m.bounce_limit` @@ -75,7 +76,7 @@ A valid `m.bounce_limit` value can be in either of the following forms: These are invalid forms, and their normalization rules upon receiving: 1. The number 0, which should be treated as missing. (This design is to simplify the development of bots in certain programming languages, such as Go.) -2. Floating-point numbers are not permitted by the Matrix protocol. +2. Floating-point numbers, which are not permitted by the Matrix protocol. 3. Any other values, including but not limited to negative numbers, strings, etc., which should be treated as the number 1. Here are two example events: @@ -128,7 +129,7 @@ The behavior of a client: 2. A bot supporting `m.bounce_limit` MUST define its own `max_outgoing_bounce_limit` value, which does not need to be shared. 1. It MUST be an integer between and including 1 and 2^53-1. 2. We RECOMMENDED that a bot allows its operator to configure the `max_outgoing_bounce_limit` to suit their needs. - 3. We also RECOMMEND `max_outgoing_bounce_limit` default to 1, or with a valid reason (e.g., due to the bot's job), no more than 3. + 3. We also RECOMMEND `max_outgoing_bounce_limit` default to 1, or in case of a special reason (e.g., due to the bot's job), no more than 3. 3. A bot is allowed to process any incoming messages, but MUST NOT send response messages (including stickers) to any incoming messages: 1. with an `m.bounce_limit` of 1 after normalization, or 2. whose `m.bounce_limit` is missing after normalization AND with a `msgtype` of `m.notice`, or @@ -208,7 +209,7 @@ There are three alternative considerations: 1. Denial-of-Service - Bot loops can cause intentional or unintentional Denial-of-Service attacks. If two bots, one supports `m.bounce_limit` and the other doesn't, there could be a risk of causing bot loops, which leads to a Denial-of-Service. However, the severity is not worse than before. A room operator's typical responsibility of keeping an eye on the bots hasn't changed, therefore, the room operator should be aware which bots don't support `m.bounce_limit` and configure accordingly. + Bot loops can cause intentional or unintentional Denial-of-Service attacks. If among two bots, one supports `m.bounce_limit` and the other doesn't, there could be a risk of causing bot loops, which leads to a Denial-of-Service. However, this proposal doesn't increase the severity than before. A room operator's typical responsibility of keeping an eye on the bots hasn't changed, therefore, the room operator should be aware which bots don't support `m.bounce_limit` and configure accordingly. 2. Information leakage from the cleartext `m.bounce_limit`. From d9669e88b7f77fece04d16fb6f0f664ce2b882cc Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 11:51:10 +0000 Subject: [PATCH 26/28] MSC4295: Minor rewording Signed-off-by: Star Brilliant --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index a23974734ae..509d5c15529 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -209,7 +209,7 @@ There are three alternative considerations: 1. Denial-of-Service - Bot loops can cause intentional or unintentional Denial-of-Service attacks. If among two bots, one supports `m.bounce_limit` and the other doesn't, there could be a risk of causing bot loops, which leads to a Denial-of-Service. However, this proposal doesn't increase the severity than before. A room operator's typical responsibility of keeping an eye on the bots hasn't changed, therefore, the room operator should be aware which bots don't support `m.bounce_limit` and configure accordingly. + Bot loops can cause intentional or unintentional Denial-of-Service attacks. If among two bots, one supports `m.bounce_limit` and the other doesn't, there could be a risk of causing bot loops, which leads to a Denial-of-Service. However, this proposal doesn't increase the severity from its previous level. A room operator's typical responsibility of keeping an eye on the bots hasn't changed, therefore, the room operator should be aware which bots don't support `m.bounce_limit` and configure accordingly. 2. Information leakage from the cleartext `m.bounce_limit`. From e629dbdecca7b59bdd234cd7abf3f5afcfb436a1 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 12:04:10 +0000 Subject: [PATCH 27/28] MSC4295: Mention MSC3955 in the Existing solutions section Signed-off-by: Star Brilliant --- proposals/4295-bot-bounce-limit.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 509d5c15529..1353a9a3283 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -31,7 +31,7 @@ The goal of this proposal is **NOT** to: ## Existing solutions -There are three existing solutions to prevent bot loops: +There are four existing solutions to prevent bot loops: 1. The `m.notice` message type: @@ -46,7 +46,11 @@ There are three existing solutions to prevent bot loops: 5. It is difficult to decide whether an AI-powered bot should use `m.notice` or `m.text`. —Should we give it the ability to interact with other bots? 6. `m.notice` is often displayed in a distinct manner, such as with a different text color, which, depending on the semantics of the message, may not always be ideal. -2. Vendor-specific tags: +2. [MSC3955](https://github.com/matrix-org/matrix-spec-proposals/pull/3955): Extensible Events - Automated event mixin + + It is similar to `m.notice`, except it has one less disadvantage than `m.notice`, because it supports multimedia messages. + +3. Vendor-specific tags: For example, Mautrix attaches the `fi.mau.double_puppet_source` tag to messages sent by a reverse puppet account. This tag is not visible to humans, but can be inspected through "View JSON Source." Mautrix won't forward a message if the sender is a reverse puppet account managed by the same Mautrix instance and the message has such a tag [[2]](https://github.com/mautrix/python/blob/8eac9db01e2b5fd9a30620bcbc8ebbaa36c71ecb/mautrix/bridge/matrix.py#L960-L964). @@ -55,7 +59,7 @@ There are three existing solutions to prevent bot loops: 1. One bot developer cannot expect all other bot developers to support their custom tag unless it's standardized. 2. Vendor-specific tags exist for a reason: they sometimes serve a different purpose than this proposal and can't replace each other. For example, `fi.mau.double_puppet_source` prevents intra-bot loops — double puppeting's unique challenge, instead of inter-bot loops. -3. An ignore list: +4. An ignore list: In the configuration file of a Matrix bot with such a feature, the operator can specify a list of users whose messages are ignored by the bot. From bdbc489b75ecfe4aa924b6f22170078babcd1b03 Mon Sep 17 00:00:00 2001 From: Star Brilliant Date: Sat, 31 May 2025 12:07:24 +0000 Subject: [PATCH 28/28] MSC4295: Mention MSC3955 in the Existing solutions section Signed-off-by: Star Brilliant --- proposals/4295-bot-bounce-limit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4295-bot-bounce-limit.md b/proposals/4295-bot-bounce-limit.md index 1353a9a3283..2899bd9ae39 100644 --- a/proposals/4295-bot-bounce-limit.md +++ b/proposals/4295-bot-bounce-limit.md @@ -48,7 +48,7 @@ There are four existing solutions to prevent bot loops: 2. [MSC3955](https://github.com/matrix-org/matrix-spec-proposals/pull/3955): Extensible Events - Automated event mixin - It is similar to `m.notice`, except it has one less disadvantage than `m.notice`, because it supports multimedia messages. + It is similar to `m.notice` but it supports multimedia messages. This solution still bears the same five remaining disadvantages of `m.notice`. 3. Vendor-specific tags: