Option to prohibit bridges of bridges to the IRC network.

[Zarthus]

Hi, I'm one of the administrators of EsperNet, which has permitted Matrix to utilize the network via the bridge. Note that this ticket is not to serve as a complaint, it's here to raise awareness and a request for a solution.

At the moment we're seeing users violate our bots policy (https://esper.net/bots.php), specifically
"Bots which create one connection per user on the opposite side of the bridge are not permitted (e.g. Bukkit IRCTransport)."

On our networks users like this exist:

(16:49:07) User catastrophe.esper.net Zomon3336262 ~discord20 2001:470:1af1:107::77 2001:470:1af1:107::77 @_discord_204441911489069056:t2bot.io
(16:49:07) User stormlight.esper.net Aardappelsaus_1429 ~discord36 2001:470:1af1:107::76 2001:470:1af1:107::76 @_discord_366602555284914176:t2bot.io
(16:49:07) User stormlight.esper.net Anna3687 ~discord22 2001:470:1af1:107::6f 2001:470:1af1:107::6f @_discord_238897961080193025:t2bot.io
(16:49:07) User anarchy.esper.net Slime_tiger7986 ~discord22 2001:470:1af1:107::6b 2001:470:1af1:107::6b @_discord_229647647059869707:t2bot.io
(16:49:07) User stormlight.esper.net Jibletz0803 ~discord2_ 2001:470:1af1:107::7b 2001:470:1af1:107::7b @_discord_289609585793433602:t2bot.io
(16:49:07) User catastrophe.esper.net witchy10002315 ~discord30 2001:470:1af1:107::7c 2001:470:1af1:107::7c @_discord_304749285721899008:t2bot.io
(16:49:07) User stormlight.esper.net TheReaverofDarkness9413 ~discord25 2001:470:1af1:107::7d 2001:470:1af1:107::7d @_discord_255026636326436874:t2bot.io
(16:49:07) User catastrophe.esper.net IvanLeshev_LBP0180 ~discord20 2001:470:1af1:107::7e 2001:470:1af1:107::7e @_discord_207834385054040064:t2bot.i```

To me I see several issues here.

1.) It looks like they are using randomized names and user ids (@_discord_3249208432098432890 is not pleasant to see)
2.) Their names are not very pleasant to look at (e.g. user29038)
3.) The 1:1 factor of connection makes it trivial to exceed the given connection limit by the server, if every discord network links through matrix through espernet we will have to continually update the connection limit.

We are also seeing similar behaviour with telegram

(16:49:06) User catastrophe.esper.net RiotTelegram ~telegram1 2001:470:1af1:107::14 2001:470:1af1:107::14 @telegram_118667124:canarymod.net

although in lesser quantity.

My proposed solution is to introduce an option that prohibits the linking of a bridge to a bridge. So that you cannot link Discord to Matrix to IRC, and only permit actual matrix clients from utilizing the IRC bridge. We're perfectly OK with Matrix users connecting, but once the bridge starts getting bridges to connect over a bridge, at some point someone will have a genius idea to bridge an existing bridge with another bridge.

In addition it might be cool to introduce an option to prohibit "unregistered" names (like @_discord_231228201626632194), I don't know where they come from but chances are it's automatically generated and not a name they chose themselves.

I have talked with the owner of t2bot.io to have them handle the discord issue, but without a fix matrix will soon exceed the threshold for the connection limit as soon as other services start doing this; and at that point we can no longer serve matrix users. (I do not think we should raise the limit because people are running 1:1 bridges on the matrix service)

---

The responsible servers I'm seeing are:

• canarymod.net (telegram)
• t2bot.io (discord)

[ara4n]

hi @Zarthus - right; when we set up the official matrix.org bridge the expectation was that it would be used like IRCCloud ('portal rooms' in matrix parlance), where a single Matrix room shadows a given IRC channel. However, what you're seeing here is 'plumbed rooms', where a given room has been plumbed into multiple networks to bridge them together.

We'll look into stopping espernet channels being plumbed via the official Matrix bridge asap (although due to funding mess we are currently hilariously undermanned on matrix IRC bridge dev, but will try to prioritise this as best we can).

[Mikaela]

See also: vijfhoek/telematrix#33 & ( #27 ) & #486 (apparently it's merged, when can we expect to see it live?) & #484.

My proposed solution is to introduce an option that prohibits the linking of a bridge to a bridge. So that you cannot link Discord to Matrix to IRC, and only permit actual matrix clients from utilizing the IRC bridge.

I think that this is possibly impossible. It might work with the bridges hosted by matrix.org and managed with "manage integrations" menu, but I don't think anything prevents third party bridges from being set up on other homeservers (Discord and Telematrix come to my mind).

In addition it might be cool to introduce an option to prohibit "unregistered" names (like @_discord_231228201626632194), I don't know where they come from but chances are it's automatically generated and not a name they chose themselves.

@_discord_ is the prefix from the bridge and 231228201626632194 their internal Discord ID which most of users aren't aware of existing.

---

2017-10-20T18:45:57+03:00: added #484 to see also.

[turt2live]

This probably relies on https://github.com/matrix-org/matrix-doc/issues/675 in a way.

[Zarthus]

@Mikaela

I think that this is possibly impossible. It might work with the bridges hosted by matrix.org and managed with "manage integrations" menu, but I don't think anything prevents third party bridges from being set up on other homeservers (Discord and Telematrix come to my mind).

Only users connecting via the matrix bridge with the /64 assigned to it are hit by our connection limit increase, matrix only needs to enable to option for their own bridge. Self-hosted bridges that connect from a different IP range entirely are totally fine, because 1:1 bridge bots would never work well on them as the connection limit increase doesn't apply for them.

[Mikaela]

All Matrix users including bridged ones regardless of their homeserver use the matrix.org bridge if they are in room that is using it.

You can see the homeserver from the end of realname, Telegram users are generally @_telegram_id:tchncs.de or...t2bot.io and they get bridged using the same range if they are on room using matrix.org brjdhe.

Sorry if I am unclear, I am currently not nrar desktop lr anything.

[Zarthus]

The problem was not resolved yet. We're still gaining connections from t2bot.io I've talked with @turt2live and he said he will clean them up in an hour.

[turt2live]

When I did a hard reset of the Discord bridge the ghost users appeared to linger around in the room, orphaned by the bridge. Seems like when the espernet bridge was restarted earlier, it happily reconnected the ghost users. I'm working on pulling them out of the room now :)

[turt2live]

Turns out my 'fix' got bitten by #461

[Mikaela]

Would AKILLing telegram*@bridge and discord*@bridge work as a workaround or would the IRC bridge just keep trying to connect and possibly trigger alerts? If it's the later case, I think another issue meeds to be opened for this too as in my opinion there can be reasons for operators to kline individual Matrix users.

[Zarthus]

We can kline them just fine, but it's far better to mediate the issue at matrix's side than at ours; as it currently marks a pretty trivial hole that can be exploited. Whenever someone decides to be evil we'd have to remove the entirety of matrix as viable connection method until it is resolved (and even then you'd have to convince us to let them back on the network again).

Each matrix user has its own IPv6 range, so it's not a problem to kline them individually. We can also, network-side, prohibit anyone not connecting from a /:matrix.org$/ realname, but neither are good
long-term solutions.

[Half-Shot]

We support this both in the form of blocking provisioning if certain user regex matches, and also just blocking the connections of users by regex.