MSC4295: Bot bounce limit - a better loop prevention mechanism

[m13253]

Rendered

(About me: I develop E2EE-capable Matrix bots and bridges tailored for two communities. Recently, I open-sourced my matrixbot-ezlogin Rust library to help people build Matrix bots without worrying about the authentication and E2EE bootstrap process.)

[turt2live]

Implementation requirements:

• Sending bot
• Receiving bot (the one that would loop)

[tulir]

This proposal doesn't appear to solve the problem that fi.mau.double_puppet_source was made for. Specifically, when a bridge sends a message from a double puppet (not a bridge ghost user), it must have some flag to prevent echoing back the message to the remote network where it came from. The flag is not meant to stop any other bridge or bot from reacting to the message, it's only meant to be detected by the origin bridge.

[m13253]

This proposal doesn't appear to solve the problem that fi.mau.double_puppet_source was made for. Specifically, when a bridge sends a message from a double puppet (not a bridge ghost user), it must have some flag to prevent echoing back the message to the remote network where it came from. The flag is not meant to stop any other bridge or bot from reacting to the message, it's only meant to be detected by the origin bridge.

It’s an honor to get a feedback from Mautrix’s side!

After understanding your explanations, I admit this proposal doesn’t solve fi.mau.double_puppet_source’s problem. In fact, this proposal seems to solve a completely different problem orthogonal to fi.mau.double_puppet_source’s problem.

1. Although both mechanisms are designed to prevent infinite loop, fi.mau.double_puppet_source prevents looping between two platforms, m.bounce_limit prevents looping within Matrix.
2. fi.mau.double_puppet_source doesn’t prevent the message being interacted by other bots or bridges, while m.bounce_limit sets a bounce limit to do so.
3. On the other hand, fi.mau.double_puppet_source doesn't deal with the situation where a room has two independent bridge instances -- e.g., one relaybot maintained by the room operator, and one double-puppet maintained by a room member on a separate homeserver --, while m.bounce_limit tries to solve this problem.

(Please correct me if my understanding is still inaccurate.)

Probably I will need to rephrase or remove this sentence. I think m.bounce_limit won’t replace fi.mau.double_puppet_source. They will co-exist, because two mechanisms solve two different problems.

[m13253]

Update: I replaced this example in the Background section with another example.

[tulir]

Extensible events already have a solution for this #3955

[m13253]

Extensible events already have a solution for this #3955

Looks interesting. The difference is MSC3955 uses boolean to mark automated messages, while this MSC4295 uses integer.

The advantage of integer TTL is it allows multiple bots to work together. — which is the biggest motivation of this proposal.

Do you think combining both ideas together is a way to go? (Extensible Events + integer TTL)

(Informally I’ll call it TTL, as networking people may be more familiar with this term. Formally it should be called “Bounce Limit.”)

[m13253]

Update: I included MSC3955 in the Existing solutions section, parallel to the m.notice subsection.

[tulir]

Bridges can and do pick up m.notice if configured to do so

[m13253]

Bridges can and do pick up m.notice if configured to do so

Thanks for your confirmation!

Indeed, I just checked the Matrix API Spec: The spec doesn’t say whether bridges should or shouldn’t pick up m.notice.

I was careless. I will rephrase this sentence.

[TheArcaneBrony]

This doesn't make semantic sense. Logically a value of 0 would mean "do not forward".

[m13253]

This doesn't make semantic sense. Logically a value of 0 would mean "do not forward".

Thanks for your comment.

Here are two explanations of this decision:

1. This is an analogy of Hop Limit in IP networks.

   An IP packet with Hop Limit of 1 means the packet is able to transmit to the recipient, but if the recipient is a router, it isn’t allowed to forward the packet to anywhere else.
   An IP packet with Hop Limit of 0, if I remember correctly, is invalid.
   Therefore, a developer who has experience with IP networking might be able to feel the current design more familiar to them, than making 0 a valid value.

2. If we make 0 an invalid value, some programming languages need some fewer steps to distinguish 0 and a missing value.

   One example of such programming languages, is Go.
   To distinguish a 0 value and a missing value, the Go struct needs to be written as:

   type OriginalRoomMessageEventContent struct {
       Body        string `json:"body"`
       BounceLimit *int64 `json:"m.bounce_limit"` // *int64 instead of int64
       ...
   }

   which uses one layer of pointer to distinguish 0 and missing, meaning slower performance (although negligible), more memory fragments, and more work on the developer side to get the logic right.
   C++ may be similar — depending on which JSON library you use.
   In other programming languages that supports nullable data types, such as Rust’s Option, C#’s Nullable, or TypeScript’s T | undefined, at least one more check is required to distinguish the missing value and to extract the valid numbers out.

Therefore, making 0 an invalid value is just simpler, faster to develop and run, and more similar to other existing network protocols.

[m13253]

By the way, I have another question: Regarding the existing Matrix protocol, if any field is invalid, how should an implementation treat it?

Should an implementation treat it as 0, missing, or reject the message at all? Perhaps this new proposal needs to be consistent in this perspective…

[TheArcaneBrony]

Sorry, seems your replies got lost in my mailbox...

Regarding the existing Matrix protocol, if any field is invalid, how should an implementation treat it?

depends on the context, generally if this is event auth, then the event should be rejected, whereas for regular client-server operation, the spec explicitly mentions that event contents are untrusted.

In response to your top level message from 9 hours ago, I feel like logically, a missing TTL on event forwarding should be treated the same as having no hops left (if you wanted to stick to the IPv4 analogy), but also one could frame it as how any person would interpret it too: there's still a ticket left to pass on, so we should pass it on. hence, missing a value outright would logically be the same as treating it as zero. (Also see null pointers in C/C++ usually being a litteral 0x00000000 pointer)

[m13253]

This doesn't make semantic sense. Logically a value of 0 would mean "do not forward".

After I evaluated @TheArcaneBrony’s comment carefully again and talked with other people who have worked with the ruma library, along with my experience in trying to implement this logic, I now agree with @TheArcaneBrony.

I plan to change the logic from “1 = stop” to “0 = stop.” I will change the proposal Markdown file in a couple of days. But before I make the change, I want to announce here to make sure no one else is simultaneously working on an implementation.

P.S.: I am currently working on a Rust implementation. First, a proof of concept echo-bot is coming soon, then I will extend to other languages than Rust and incorporate it to some real-world bots.

[m13253]

A new version has been pushed to the branch. The biggest modification is the behavioral change from “1 = stop” to “0 = stop.”

I also defined clear rules when dealing with multiple input messages rather than leaving it as an open question. I also removed the description about Telegram’s bot-to-bot restrictions, which is now outdated.

I added some more discussion about whether m.bounce_limit lying outside encryption envelope does or doesn’t affect security. I feel I might be playing with fire, so I really want to hear more ideas from other people.
(Or, should I just be safe, putting it inside the encryption envelope, and abandon my “UTD bot” idea?)

A working PoC called echo-bot is available at: https://codeberg.org/m13253/matrix-echo-bot or https://github.com/m13253/matrix-echo-bot (They are mirrors of each other.)
Please compile with --features unstable-msc4295 to use bounce limit to prevent looping; with --features allow-looping to allow looping; with no feature flags to use m.notice to prevent looping.
Please add two instances of echo-bot into the same room, and use a human account to send an initial message as a seed. You will be able to observe their looping or loop prevention behavior.
I am currently working to implement it on real-world bots other than this simple echo-bot.

Finally, since I have been iterating on the branch for multiple commits, I am keeping all the historical commits so we don’t lose track of the comments tagged to those commits. Please instruct me whether and when and how I should squash the git history.