search

matrix-org / matrix-spec

The Matrix protocol specification
Apache License 2.0
197 stars 97 forks source link

Prevent AS routing loops (SPEC-131) #31

Open matrixbot opened 9 years ago

matrixbot commented 9 years ago

Problem: Two application services A and B are on IRC channel #foo. They both echo messages when a new IRC user joins the room, and when new Matrix users join the room. Alice on IRC joins the room:

[ ] indicates the **sender**

         IRC Channel                            Matrix Room
~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~~~--~~-
[IRC] Alice has joined #foo.
                                      [A] IRC-Alice joined.
                                      [B] IRC_Alice joined.
[B] IRC-Alice has joined #foo.
[A] IRC_Alice has joined #foo
                                      [A] IRC-IRC-Alice joined.
                                      [B] IRC_IRC_Alice joined.
[B] IRC-IRC-Alice has joined #foo.
[A] IRC_IRC_Alice has joined #foo.
                                      [A] IRC-IRC-IRC-Alice joined.
                                      [B] IRC_IRC_IRC_Alice joined.
...

We should advise that AS developers mark virtual users as 'bots' and ignore bot traffic to prevent this. However, we need stronger guarantees to prevent this to avoid flooding both the IRC channel and Matrix with events.

One technique would be to put a new state event which is enforced by home servers which determines which HS domains can use application services to monitor this room, e.g. the room pointed to by #irc_python:matrix.freenode.net may have a state event saying only application services registered to the HS domain matrix.freenode.net should be passed events in this room. This breaks the infinite loop on the Matrix end by preventing B from receiving the join events. This relies on home servers implementing these rules, which is deemed more probable than relying on ASes to implement these rules, given we expect there to be many more AS implementations than HS implementations.

Alternative suggestions welcome.

(Imported from https://matrix.org/jira/browse/SPEC-131)

(Reported by @Kegsay)

matrixbot commented 9 years ago

Jira watchers: @erikjohnston @Kegsay @ara4n

matrixbot commented 9 years ago

Links exported from Jira:

relates to BOTS-46

matrixbot commented 9 years ago

On the other hand, we probably do want to support multiple bridges if they are bridging to different protocols/endpoints. For example, having an IRC and XMPP bridge in the same room. In fact, it's not unreasonable to have a matrix room bridged to multiple IRC channels/networks.

-- @erikjohnston

matrixbot commented 9 years ago

Absolutely - it's critical to support multiple ASes bridging (matrixing?) a single Matrix room with multiple foreign channels (IRC servers, XMPP servers, Gitter, etc). But it's a disaster if any random user in the room can go and absentmindedly fire up an AS to bridge that room into an IRC channel which overlaps with an existing IRC bridge... and cause a join or message loop. Hence suggesting you explicitly state which HSes are allowed to run AS bridges for a given Matrix room, so that the room admins can instruct well-behaved ASes to avoid looping disaster.

A nice side-effect is that this list of authorised bridges can also be used as useful metadata to detail which foreign rooms a given matrix room is linked to. (e.g. "ooh, this is bridged to irc://irc.freenode.net/matrix as well as xmpp://wherever!", and show it to the user/client as part of the room metadata).

-- @ara4n