MSC4295: Bot bounce limit - a better loop prevention mechanism

Author: m13253

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:
@@ -201,7 +202,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.
-
+s
 2. Information leakage from the cleartext `m.bounce_limit`.
 
    This is discussed in the [Alternatives](#alternatives) section.