Interconnecting XMPP and IRC

IRC

IRC (Internet Relay Chat) is a real time text chat service. Although it can be used for 1:1 user chat, it is primarily used for group chat, using “channels”. The IRC client to server protocol is specified in RFC 1459, and this is widely supported by IRC clients and servers. Although there are standardized IRC server to server protocols, in practice server to server protocols vary between implementations and IRC services usually all use the same server implementation.

A network of servers is connected as an acyclic graph, as shown above. Channels are usually global across the network. A client can join a channel without authentication – the only requirement is that the client presents a unique name. This lack of security makes IRC very straightforward to deploy and operate.

XMPP

XMPP (eXtensible Messaging and Presence Protocol) provides a general purpose mechanism for real time communication. Clients connect to a local server, which will connect directly to the server of the destination client. Thus all servers are fully and directly interconnected, as shown below. Client/Server and Server/Server protocols and standardized and interoperable between different client and server implementations. The protocols provide comprehensive security.

XMPP is commonly used to provide 1:1 chat services, which is built directly onto the core XMPP service.

Multi-User Chat (MUC) is standardized for XMPP and widely used. In standard MUC, a MUC room is co-located with an XMPP server. Messages will flow across the XMPP network to the MUC room, which will send the message on to all of the MUC room members. This operates in a similar manner to an email mailing list.

Federated MUC (FMUC) is a new standard, which federates the MUC room over multiple nodes, operating more like an IRC channel. This is described further in the white paper [Federated Multi-User Chat: Efficient and Resilient Operation over Slow and Unreliable Networks].

Existing XMPP Gateways to IRC and other Services

There are a number of XMPP gateways to other protocols and services. These are typically built using the XMPP standard Component Protocol (XEP 0114) which is designed to integrate third party services. This approach works well to support 1:1 communication between XMPP clients and users on centralized IM services such as MSN.

This approach is used in a number of XMPP to IRC gateways. These gateways will allow XMPP users to address IRC users and channels. The gateway will connect to the IRC service (as a client) and will appear as an IRC client (with a username derived from the XMPP username (jid)). Gateways of this nature allow XMPP clients to connect into IRC channels. This basic approach is workable, but has a number of disadvantages, which will become clear in the next section.

The M-Link IRC Gateway

In the M-Link IRC Gateway, a key part of the design is based on the observation that IRC Channels are equivalent to XMPP MUC rooms. The gateway operates by associating a MUC room with an IRC channel, by configuration in the M-Link server and MUC room, as shown below.

This diagram also shows how this IRC/XMPP gateway operates with distributed IRC and XMPP networks. On the IRC side, a channel will be shared on all IRC servers, and IRC clients connect to the channel on their local server. On the XMPP side, the MUC room is operated on the M-Link server providing the gateway. This MUC room can support users directly connected to the server, and users connected indirectly by XMPP server federation.

The M-Link Gateway uses the IRC client to server protocol, to connect to IRC, in order to maximize interoperability with different IRC servers. To do this, it will maintain an IRC connection for each MUC room member and send messages to the IRC channel on an appropriate link. Connections are shared between (gatewayed) MUC rooms. The IRC Nickname will be based on the MUC Nickname of each user (identical where IRC constraints allow). Incoming messages from IRC will arrive on each link, and M-Link will ensure that just one message is distributed to the MUC room. This approach leads to a 1:1 equivalence between IRC channels and XMPP MUC rooms. This has a number of advantages:

• The involvement of IRC is totally transparent to the XMPP user. The user will see a normal MUC room, which just happens to be connected to an IRC channel.
• The XMPP administrator has control of MUC room naming, which does not have to match IRC channel naming.
• Full MUC functionality is available locally, for example MUC access control and affiliation management.
• There is no downgrade of security for XMPP users with XMPP traffic. XMPP users are still authenticated and connections are protected with TLS.
• Security label support is available, including translation to IRC users as FLOT labels in the IRC messages. See [Using Security Labels to Control Message Flow in XMPP Services].

The above screenshots show the M-Link IRC Gateway in action. The first screenshot is the of the Swift XMPP client connecting to a MUC room. The second screenshot is the mIRC IRC client connecting to the IRC channel that is linked with the MUC room. It can be seen that IRC and XMPP users get a very similar view of communications.

IRC to XMPP Migration

IRC is widely used on military networks. Many military networks wish to upgrade from IRC to XMPP, and the approach taken by the M-Link IRC Gateway facilitates this.

If an IRC gateway using the simpler approach described earlier is used, XMPP clients connect to an IRC channel via the gateway and so communication always goes through the IRC channel. This means that all service is brought down to the IRC level and there is no mechanism to turn off IRC, even when no native IRC users remain.

With the M-Link model, an XMPP MUC room is created to match each IRC channel. As users move from IRC to XMPP they can be added to the XMPP MUC room. Then, when no IRC users remain, the IRC channel can simply be turned off, and this will be completely transparent to the XMPP users. This provides a sound migration model.

Conclusions

This paper has described the capabilities of the M-Link IRC Gateway capability, and how its approach of mapping MUC rooms with IRC channels enables easy operation, maximizes security and functionality capabilities for local XMPP users, and provides a solid migration approach from IRC to XMPP.