Using bridges

↩ home

If you don't know what bridges, IRC, or Matrix are, skip ahead to the final section.

Bridging to IRC

You can join IRC channels by joining #<channel>%<IRC server>@<Biboumi server>. For example -

#commonlisp%irc.libera.chat@irc.jabberfr.org

In addition to irc.jabberfr.org, hmm.st is another public Biboumi instance.

Similarly, you can send PMs to <username>%<IRC server>@<Biboumi server>. For example, to register your nickname on OFTC, send a message to -

nickserv%irc.oftc.net@irc.jabberfr.org

For more information, check out the Biboumi user documentation.

Persistent IRC connections

You probably want to make Biboumi's connection to an IRC channel persistent. That way, you will remain in the IRC channel, even if your XMPP client is disconnected. That prevents sending excessive joins and parts to the IRC channel if you have a patchy network, and you won't miss the room history when disconnected.

For that, you may need to make a one-off configuration for each channel using an XMPP client which supports Ad-Hoc Commands (AHC). These include -

  • Converse.js or Movim (web)
  • Gajim (desktop)
    • open an IRC channel, click on the overflow menu - "Execute Command" - "Configure a few settings for this IRC channel" - enable "Persistent"
  • Monocles Chat (Android)
    • open an IRC channel, and tap on the "Commands" tab - "Configure a few settings for this IRC channel" - enable "Persistent"
  • Poezio or Profanity (terminal)

Bridging to Matrix

You can speak to Matrix users by adding <user>_<domain>@<Bifrost server> as a contact. For example -

alice_matrix.org@aria-net.org

You can join Matrix rooms by joining #<room>#<Matrix server>@<Bifrost server>. For example -

#malleable-systems#matrix.org@aria-net.org

Some rooms need a different syntax, such as the OSM IRC channel -

#_oftc_#osm#matrix.org@aria-net.org

In addition to the aria-net.org Bifrost instance, there's also one on matrix.org, but it has fewer features.

You can also bridge a Matrix and an XMPP room together, so that the XMPP room is discoverable to XMPP users via search.jabber.network, and if either one goes down, the other keeps running as usual.

  1. Invite @_bifrost_bot:aria-net.org to the Matrix side
  2. Type !bifrost bridge xmpp-js <XMPP room domain>.<tld> <XMPP room name>

You can join The Lighthouse for help with the aria-net.org bridge.

The downsides of bridges

While bridges are rather fashionable at the moment, there are several serious issues with them that conventional wisdom usually downplays.

In most cases, bridges are developed and encouraged only as far as they can help existing communities move to somebody else's ecosystem. The one controlling the new ecosystem is usually a heavily-funded party with the motive of poaching users. These parties may have you convinced (through excellent marketing) that their motives are purely altruistic, but look even a little closer and the façade fizzles away.

Downsides of bridges in general

  1. Spam
  2. Downtime, resulting in dropped messages
  3. Messages arriving out of order
  4. Being restricted to the mutually-supported subset of functionality.
  5. Bridges may expose your XMPP address to all participants.
  6. Bridges in general destroy any data sovereignty/privacy assurances you might otherwise have had. This is important even for public rooms. This is especially relevant when bridging to proprietary networks, but also when bridging to Matrix.

Downsides of bridges to proprietary networks

  1. Bridges keep us stuck in the past instead of improving things. Instead of helping people get away from legacy, proprietary, or centralized networks, bridges help people stay on them. They can even encourage people to move away from free networks to proprietary/centralized networks.

Downsides of Matrix bridges in particular

  1. As with Matrix itself, Matrix bridges give a false sense of increased population - typically a 10:1 ratio of ghost users to real users. Plenty of people fall for this trick and are tempted to bridge to Matrix. Obviously, this inflated participant count does not result in an actual increase in activity.

  2. Matrix-XMPP bridges change XMPP links to Matrix links, so Matrix users don't have to leave Matrix to use XMPP.

    On the other hand, the same bridges don't similarly translate Matrix links for XMPP users, thereby encouraging them to join Matrix.

    This gives further weight to the suspicion that bridges are really a means of poaching users.

  3. Matrix bridges (just like Matrix servers) require significant server resources and human effort (in maintenance) to run. Low-resource community-run bridges may thus suffer from significant downtime. They can also take an age to connect to.

Parting words on bridges

Bridges are antithetical to my aim of moving people from proprietary and centralized networks to federated networks of freedom-respecting software. Thus, I prefer to be in unbridged XMPP rooms, and to get existing communities to move to XMPP.

Further reading - freie-messenger.de/en/matrix/gedanken/#bridges