____________________________________________ REFLECTIONS ON IRC, AND PAIN WITH TELEGRAM Brett Gilio ____________________________________________ <2020-09-18 Fri 21:11> Table of Contents _________________ 1. Singing Praises, Crying Woes 2. Generational Differences 3. A note on IRCv3, and `orcircd'. Have a response? Errata: 1 Singing Praises, Crying Woes ============================== IRC is one of those networking and communication protocols that ages well with the internet. Free software lovers, developers, and casual netizens (especially those born before the millenium) have created the infrastructure for discussing topics we are passionate about. Freenode and OFTC both have systematically helped structure not only project coordination and collaboration, but have created lasting ties between people as free software is an inherently social act. IRC represents freedom to many of us, and it is becoming unique again as other protocols such as XMPP slowly fall out of favor to the often proprietary, privacy invading, and untrustworthy competition. This is where I disclaim that I use Telegram[1]. I was introduced to that platform a number of years ago, and was my first real connection point between like-minded developers and math nerds. Telegram is featureful, and able to sustain (and often surpass) parity with other platforms like Signal, WhatsApp, and other miseries. However, Telegram has been losing its esteem from my point-of-view over the last number of years. Telegram suffers from too many problems: unnecessary features eerily resembling scope creep from the maintainers, over-engineering their network to support D.O.A. bloat such as TON (for reasons beyond my comprehension), and buying into the latest marketing buzz about blockchain'ing all-the-things. Additionally, the Telegram development has failed to keep its promises on many high demand features for years! For example, releasing their server-side source code. My real big pain point with Telegram is that their funding model is cryptic, and relies on this unknown fortune of some "entrepreneur" named Pavel Durov[2]. Even the official website massages away all concerns about the source of funding by being generally blasé. They assure the users that they are not profiting off of user data[3]. How likely is this? I don't know. But the real question is, do you trust it? If Pavel Durov is arrested and all of his assets seized, what is the protection that Telegram will offer me from the Five Eyes (or whatever intelligence agency exists outside of that realm). Additionally, Telegram does not guarantee any level of anonymity should you request it. To use Telegram you must register through a telephone number. If you are like Richard Stallman, you probably do not have a cellphone with MMS/SMS functionality. I do, but I do find it rather disconcerting that this is not optional to use the platform. Between all of these apparent problems I have slowly but surely been moving to my other network of choice, IRC. 2 Generational Differences ========================== I am rather young, but I am old enough to remember using AOL Instant Messenger and MSN Messenger on my Windows XP machine. Back then you were given particular contraints to work in. You had to understand your vulnerabilities of your machine (especially if you were using Windows), and you had to reason with the constraints offered by the protocol you were messaging on. In those days, I was introduced to programming via Visual Basic 6 and C++. My go to hobby was writing exploits for AOL's OSCAR[4] and TOC[5]. These exploits took advantage of specific vulnerabilities in message handling, DCC exchanges, and lack of flood-prevention to cause some nuisance effect to others on those platforms. The fun of this, besides being a nuisance to others, was that you were forced to reason with the limitations of those networks. IRC is similar (except most IRCd implementations are FAR more secure and not as easy to exploit with a good client) in that you are set with some limitations. IRC is generally not going to handle your images, distribute some minified JS to give you some animated sticker pack, etc. What IRC excels at is cheap, reliable infrastructure. This is different from your Telegram, WhatsApp, Signal, or (RMS forbid) Discord. While Slack and Matrix are in varying degrees based on the IRC protocol even their extensions have severely limited the variations of clients that get first-class support. This is in great contrast to IRC where well crafted clients are available in just about every crevice of your (mostly) standard GNU/BSD/Plan9 system. Even Emacs comes pre-packed with two (maybe three, who knows) IRC clients[6][7] built into it with many more that can be fetched and plugged[8]. Drew DeVault wrote an article[9] which exemplified wonderfully that the "lack of features" on IRC are a positive, alluding to how poorly and/or over-engineered your other choices are today. For most of these features, I think that people who have and think they need them are in fact unhappier for having them. What are some of the most common complaints from Slack users et al? “It’s distracting.” “It’s hard to keep up with what people said while I was away.” “Threads get too long and hard to understand.” Does any of this sound familiar? Most of these problems are caused by or exacerbated by features which are missing from IRC. It’s distracting because your colleagues are posting gifs all day. It’s hard to keep up with because the infinite backlog encourages a culture of catching up rather than setting the expectation that conversations are ephemeral. -- Drew DeVault This is further complimented with the fact that it takes leaps-and-bounds more effort to port your Discord client to some unconventional (possibly custom) operating system. To port an IRC client, it is much more trivial and at the least you can get to communicate more quickly because the protocol is just not nearly as convoluted or cumbersome to wrestle with. 3 A note on IRCv3, and `orcircd'. ================================= This short article wouldn't be complete without making a few tangential remarks. First, IRCv3 is a work in progress to assist in creating a modernized next-generation IRC protocol standard. Some parts of this are ratified, many are still in draft phase. Some of the drafts are absolute lunacy, and others are quite nice (I do not wish to specify here, lest I make enemies). With the IRCv3 protocol, and my recent turn to IRC in general I have been doing research on various IRCd implementations out there as well as reading the RFCs. IRC is absolutely fascinating! I have started somewhat of a research pet project to combine the latest innovations of OCaml and take standard IRC and IRCv3 specifications to create my own IRCd. With this I have had a lot of help from friends who are interested in contributing, as well as the OCaml community, and many Freenode staffers. Hopefully something comes of this. Here is a list of various IRCd server implementations: - [inspircd] (C++) - [oragono] (Go) - [unrealIRCd] (C) - [ircd-seven] (C) - [miniircd] (Python) - [matrix-ircd] (Rust) - [orcircd] (OCaml) /Work in progress/ ---------------------------------------------------------------------- [inspircd] [oragono] [unrealIRCd] [ircd-seven] [miniircd] [matrix-ircd] [orcircd] Have a response? ================ Responses and discussion pertaining to any of the blog entries on my website are welcome! Start a discussion on the [mailing list] by sending an email to [~brettgilio/blog-discussion@lists.sr.ht]. [mailing list] [~brettgilio/blog-discussion@lists.sr.ht] Errata: ======= - <2020-09-23 Wed 11:31> Fix dead links and grammar. ---------------------------------------------------------------------- Footnotes _________ [1] [2] [3] [4] [5] [6] [7] [8] [9]