Internet Relay Chat (IRC) and Kludges

Internet Relay Chat (IRC) is an archaic protocol developed in the days where mail servers, newsgroups and BBSes were common (e.g. predates HTTP and the web). The idea behind the protocol, like others of its time, is that clients would have their textual messages relayed by a centralized server to other clients, with the innovation of IRC being that it supported real-time multi-user communications (BBSes were sometimes single user and mailservers/newsgroups asynchronous).

While it is unfortunate that electronic mail is here to stay, BBS, newsgroups and IRC are luckily just about dead.

Since IRC does not support anything besides exchanging text through a centralized server, modern IRC clients have had to incorporate other protocols to help facilitate functionality for which the protocol was never intended (e.g. file exchange).

The first kludge is called Client-to-Client Protocol (CTCP) that allows IRC clients to send short messages directed to a specific clients instead of to a #channel. Textual CTCP messages are still sent to the central server but are forwarded to only to a specific client.

The second kludge is called Direct Client-to-Client (DCC) protocol that allows a prolongued exchange of either text or binary data in a way that was never intended to be cross-client. Awesome.

Enter: file servers (Fserves). Clients can use CTCP to open DCC chat sessions where one client sends text like "dir" and the other responds with a text corresponding files on their local disk. Then "get thatFile.txt" happens and the file is transfered over DCC. Simple right? No.

Since DCC does not transfer the file on the same port as either of the active DCC or IRC connections, and since the kludge known as NAT breaks the internet, most DCC transfers will fail without yet another kludge called port forwarding and/or the reverse DCC kludge (depending on specific configurations between endpoints). In addition, since neither CTCP nor DCC were written as a formal client agnostic protocols, their practical implementation is actually client specific.

eXtended DCC (XDCC) is an automated version of the Fserves concept and clients interact with it similarly (CTCP messages). Directory listings, text files known as "pack lists," are published over either DCC or HTTP. The CTCP triggers are thus known in advance so a client can DCC request a specific file without the intermediary DCC connection necessary in Fserves.

These scripts/programs that connect to IRC networks/channels, monitor chat and respond to triggers, like !list and @find, are known as "bots."

Since CTCP is IRC server specific, it means the IRC server knows about every pack transfer attempt. It also means that it is possible to send "/ctcp Bot xdcc send 23" to the IRC server and the bot (if connected) should respond by sending the appropriate pack without either the client or the bot joining any channels or registering any nicknames. That said, some bots require the client of the DCC request to have a presence on the same channel as the bot. XDCC bots also typically respond to "/ctcp bot version," "/ctcp Bot ping" and "/msg Bot time."

We already have a protocol capable of point-to-point file transfers, that uses standardized sub-protocols with well developed server-client authentication and encryption technology with native clients on every system. It’s called HTTP. Binary transfers over DCC is a kludge of a kludge that just needs to die.