matrix-appservice-irc VS nimb

The issue in question here is https://github.com/matrix-org/matrix-appservice-irc/issues/1... (and https://github.com/matrix-org/matrix-appservice-irc/pull/133...) which accidentally regressed due to other stability work done for Libera (specifically, keeping the IRC-side connections persistent, rather than reconnecting when the bridge starts). As a result there was an race condition edge case where users on the Matrix side could read history in the IRC channel while still connecting the Matrix users on the IRC side. This was one of the straws that broke the camel's back in terms of Libera wanting the bridge disabled. The other was the confusion over https://matrix.org/blog/2023/07/what-happened-with-the-archi....

As a user, this is miserable. Matrix is used as a decentralised bouncer for tens of thousands of users to access IRC (including me) and while the bridge has certainly had problems over the years (e.g. occasional delays & a recent spate of dropped messages), it's also improved loads too - e.g. with support for restarting the bridge without reconnecting all the IRC users (https://github.com/matrix-org/matrix-appservice-irc/issues/1...) and all the other stuff in https://github.com/matrix-org/matrix-appservice-irc/blob/dev....

By now requiring users to go and contact chanops to ask them to explicitly plumb IRC channels to Matrix, it's just going to waste time for chanops, precipitate weird cross-plumbing failures, or fail outright (given plumbing channels with more than 100 users has to be done manually to prevent abuse).

It's very unfortunate that it's come to this, and I can only hope that the whole "opt in with a chanmode" thing happens.

In fact, wouldn't it have been better to just ban the bridge by default, and let chanops unban it if they want people to be able to access via Matrix, rather than encourage people into the weird world of plumbing?

On the Matrix side, we've put a lot of effort into being good neighbours, fwiw - e.g. recently this massive refactor at https://github.com/matrix-org/matrix-appservice-irc/pull/166... to allow the matrix<->irc bridge to be restarted without reconnecting all its IRC users (the single biggest complaint we ever had about the bridge in terms of eroding usability of IRC for IRC natives).

Sadly it looks like it wasn't considered sufficient, based on https://libera.chat/news/matrix-deportalling.

This happened right after Freenode banned IRCCloud users following IRCCloud staff statements suggesting users to migrate off Freenode and the launch of competing bouncer services.[0] Now that most channels are dead and direct users to other networks despite staff's best efforts to quell any criticism (channel migrations+topic-renaming, banning users, etc), I guess they decided to wipe everything and start over to more easily remove any references to Libera/OFTC. In fact, it removes any every reference to anything at all.

If you had a bot that directed users to the actual location of your community, you should check to make sure that it survives this migration (this was probably part of the intent).

If you use Matrix and have left Freenode channels, the IRC-Matrix appservice bridge might still be keeping you connected. To leave Freenode, send a "!quit" message to the Freenode bridge appservice user, @appservice-irc:matrix.org.[1][2]

[0]: https://web.archive.org/web/20210612224853/https://nitter.ni...

[1]: https://matrix-org.github.io/matrix-appservice-irc/latest/ad...

[2]: https://github.com/matrix-org/matrix-appservice-irc/wiki/Bri...

Matrix bridging to Libera is already functional in testing and should be announced soon, subscribe for news to this issue.

It looks like they could be fixed as the bridge code is open source. For example here is an issue around messages being split incorrectly: https://github.com/matrix-org/matrix-appservice-irc/issues/1...

Your security advisory has been quite helpful and I could reproduce the issue involving CR. It is particularly enlightening to know that the null byte could also cause the same issue because some IRC servers may interpret the null byte too as a line ending.

It is late here but I have pushed a quick fix to plug this loophole: <https://github.com/susam/nimb/commit/c5d6c4c>. Review comments, feedback, pull requests, patches, etc. are very welcome! This comment thread has been productive and constructive. Thank you!

Review comments, pull requests, feedback, etc. are welcome. T

I have had my own share of problems with both portalled rooms as well as plumbed rooms on Matrix. Dropped messages, dropped connections, etc. Sometimes the re-connection times can be several hours long. Despite these problems, the portalled rooms have been a convenient way for many IRC beginners to quickly set up a relatively persistent connection to the IRC network via the Matrix bridge. That convenience is now going to be lost unless the IRC channel operators opt-in to set up a plumbed room on Matrix and sufficiently advertise the plumbed rooms.

As a channel moderator, I haven't been too happy with the plumbed channels either. For example, one of the things I have found to be a little problematic is that the Matrix bridge service joins the Matrix room with Admin power level. To avoid these complications, I wrote my own tiny script to bridge the Matrix rooms and IRC channels I needed. Since my script joins the networks as regular clients, it does not need elevated privileges in the channels/rooms. In case, anyone is interested in the script, I have it available here: https://github.com/susam/nimb

The section "Differences from Matrix Appservice" at the bottom of the README in the preceding link explains some of the inconveniences I faced with the Matrix bridge service for plumbed channels and why I had to write my own script to avoid them.