The postmarketOS chat rooms are available on both the Matrix and IRC protocols (IRC on OFTC). Communicating from one protocol to the other is possible via matrix-appservice-irc. We have been using the instance hosted by the Matrix.org Foundation, which will probably get shutdown at the end of March 2025. This would be today, we haven't heard any further information whether it will actually happen or not and when. But as of today we are now self-hosting the bridge.
Evaluation
First we considered going Matrix-only since the majority of our uses are on that protocol. But via our Mastodon poll and direct feedback via chat it was apparent that a lot of people still want to be able to use IRC for talking in the postmarketOS channels so we investigated how to make this possible.
Next we decided whether to self-host a bridge or using a 3rd party offering. Our conclusion was that for us since we already run a Synapse instance, the maintenance effort should be rather minimal after we do the initial setup of the bridge. So we are trying that first, and only if it turns out to be more work than expected we will switch to a bridge that is hosted by somebody else.
We had to figure out which software to use for the bridge since the Matrix.org Foundation wrote regarding matrix-appservice-irc that they "will also mark the software behind those bridges as archived". The heisenbridge project had a very useful comparison table, through which we realized that we want to keep using a version of matrix-appservice-irc, as it seems to be the only one that can currently do the full single puppeting mode. All others would either show up as one user on IRC or on Matrix side.
matrix-appservice-irc runs in full single puppeting mode where both IRC and Matrix users are puppeted both ways. The Matrix users identity is directly mapped to IRC and they are in full control. This method of bridging creates multiple IRC connections which makes is mostly transparent for both sides of the bridge. As the room and channel permissions are synchronized between IRC and Matrix (where applicable) means a Matrix user joining a Matrix room needs to be able to connect and join the IRC channel through the bridge as well. Any Matrix user joining plumbed or portal IRC rooms are automatically connected to the IRC network.
We set on the pixie.town fork of matrix-appservice.irc since it has a number of patches that improve the bridging experience. Though this is not a consistently maintained fork either, we still evaluated it as our best option currently. Many thanks to Foks for their work!
Talking to OFTC
In case you want to set up such a bridge yourself, you should talk to the IRC network that you will bridge with. Folks from OFTC told us that they strongly prefer if each user bridged from Matrix to IRC has their own IPv6 address, so they could be banned separately if needed. Also OFTC has relaxed their limits for us so we can have more connections from our subnet.
Using the bridge
Official channels: As of today the official postmarketOS channels have already been switched over to use our new bridge for synchronizing messages across both protocols. You don't need to do anything, it should just work as before. Note that when you send a message from Matrix in a bridged channel for the first time, you will get a message from "OFTC IRC Bridge status" (@oftc:postmarketos.org) as shown in the screenshot below. You can use this to set your nickname, open this bridge status chat and type !help for more information.
Related channels: People who own channel(s) related to postmarketOS, such as the Sxmo channel or a mainlining channel for a specific SoC, can request that we configure the bridge for that channel as well by creating an issue here.
Portalling: The bridge also has a portalling feature, which allows joining IRC rooms from Matrix which don't have an equivalent Matrix room. However since this feature could be misused we are only offering this for members of the postmarketOS team (Core Contributors and Trusted Contributors).
Feedback & Thanks
Let us know if things are not working as expected (e.g. via chats or Mastodon). Thanks to Luca, Ferass, Oliver for setting up and maintaining the bridge, to Foks for the fork, and the fine folks at OFTC for the limit exceptions and the configuration recommendations! If you appreciate this blog post and want to help us with our infrastructure cost to keep this bridge running among other things then consider contributing financially via OpenCollective.