Bridging and Integrations

Bridging

Bridging with IRC

Bridging with Ubuntu IRC is being investigated with the IRC Council. This is the only bridging priority at the moment. IRC is the official Ubuntu synchronous communications tool and having a stable, self hosted bridging solution is really important. It is also important to get it right. Please stay tuned here for further information

Bridging with other chat platforms

Self hosting bridges with chat platforms outside of IRC is currently not on our roadmap.

Integrations

Integrations showroom

If you want to see what Matrix is capable as a platform, you can have a look at our showroom space and rooms. You can join this public space and the rooms in it. Various integrations are displayed as examples. All integrations used are hosted by Element.

Element hosted integrations

A series of integrations hosted by Element are available on the Ubuntu Matrix instance. Room admins need to decide if they want to grant use of those or not. Please note those are not provided by Ubuntu, and the Ubuntu project cannot guarantee uptime for those integrations.

Ubuntu self hosted integrations

We are currently considering various self hosted integrations, but we are unable to provide further information or timeline yet.

2 Likes

It’s great to modernize a platform to newer technologies and it’s great to find a technology more in tune with today’s needs and communications preferences.

However, the idea of “bridges” is not well thought out, and poorly executed.

IRC has many limitations, one of the most common is line length. A message exceeding 400 characters results in the message being broken up to blocks and transmitted successively. An issue with the bridge is that when this breaking of messages, each successive message will not carry the tag to indicate who has sent the message. If more than one person is sending large amounts of text, this will degrade the user experience with different topical message commingling with the successive postings.

The next part is the tagging of messages passed through the bridge. The tag is way too long and reflects and being in the format of <{username} (@{matrix_channel}:{matrix_server_domain})>. The length of which can be cannot be controlled and can potentially exceed 255 characters in length (recalling a max line length of 400.) Knowing that matrix servers have long names (e.g. llllllllllllllllllllllllllllllllllllllllllllllll[dot]space) this is going to create a very verbose post each time a message passes through the bridge gateway.

Which is the next issue, tagging a person. Currently clients offer a tab completion to emulate an effective @ reply. That will not exist for either side of the bridge gateway. Personally I have never seen anyone provide an effective answer to this problem. Just that “assume it works.” If looking at the support channel where it’s very important to tag a message to the user it is intended, it will be a very degraded experience when the wrong person is tagged because of similar resemblance to the target name. Creating a large amount of confusion, especially in a channel with a lot of activity.

Taking two very different communications technologies and mashing them together just doesn’t make any sense. To do it effectively would mean the need to remove the features that make one platform more versatile, to meet the needs of the lesser capable.

Just let IRC and Matrix communities be independent. Embrace that there will be some people that prefer one over the other. Be okay that if this means the closure or demotion of IRC to an unofficial community, let that that happen. The many features of Matrix bring a lot of opportunity, but having to adapt everything to an older technology will always create a degraded experience for everyone.

1 Like