logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Absence-of-features-in-IRC.md (6683B)


  1. ---
  2. date: 2019-07-01
  3. layout: post
  4. title: Absence of certain features in IRC considered a feature
  5. tags: ["philosophy", "irc"]
  6. ---
  7. The other day a friend of mine (an oper on Freenode) wanted to talk about IRC
  8. compared to its peers, such as Matrix, Slack, Discord, etc. The ensuing
  9. discussion deserves summarization here. In short: I'm glad that IRC doesn't have
  10. the features that are "showstoppers" for people choosing other platforms, and
  11. I'm worried that attempts to bring these showstopping "features" to IRC will
  12. worsen the platform for the people who use it now.
  13. On IRC, features like embedded images, a nice UX for messages longer than a few
  14. lines (e.g. pasted code), threaded messages, etc; are absent. Some sort of
  15. "graceful degradation" to support mixed channels with clients which support
  16. these features and clients which don't may be possible, but it still *degrades*
  17. the experience for many people. By instead making everyone work within the
  18. limitations of IRC, we establish a shared baseline, and expressing yourself
  19. within these limitations is not only possible but makes a better experience for
  20. everyone.
  21. Remember that [not everyone is like you][old hardware]. I regularly chat with
  22. people on ancient hardware that slows to a crawl when a web browser is
  23. running[^1], or people working from a niche operating system for which porting a
  24. graphical client is a herculean task, or people with accessibility concerns for
  25. whom the "one line of text per statement" fits nicely into their TTS[^2] system
  26. and screenreading Slack is a nightmare.
  27. [^1]: Often, I *am* this person.
  28. [^2]: Text to speech.
  29. [old hardware]: https://drewdevault.com/2019/01/23/Why-I-use-old-hardware.html
  30. Let's consider what happens when these features are added but non-uniformly
  31. available. Let's use rich text as an example and examine the fallback
  32. implementation. Which of these is better?
  33. <span>(A) &lt;user&gt; check out [this website](<a href="https://example.org">https://example.org</a>)</span>
  34. <span>(B) &lt;user&gt; check out this website: <a href="https://example.org">https://example.org</a></span>
  35. Example B is what people naturally do when rich text is unavailable, and most
  36. clients will recognize it as a link and make it clickable anyway. But many
  37. clients cannot and will not display example A as a link, which makes it harder
  38. to read. Example A also makes phishing *much* easier.
  39. Here's another example: how about a nice UI for long messages, such as pasted
  40. code snippets? Let's examine how three different clients would implement this:
  41. (1) a GUI client, (2) a TUI[^3] client, and (3) a client which refuses to
  42. implement it or is unmaintained[^4].
  43. The first case is the happy path, we probably get a little scrollbox that the
  44. user can interact with their mouse. Let's say [Weechat](https://weechat.org/)
  45. takes up option 2, but how do they do that? Some terminal emulators have mouse
  46. support, so they could have a similar box, but since Weechat is primarily
  47. keyboard-driven (and some terminal emulators do not support mice!), a
  48. keyboard-based alternative will be necessary. Now we have to have some kind of
  49. command or keybinding for scrolling through the message, and picking which of
  50. the last few long messages we want to scroll through. This will have to be
  51. separate from scrolling through the backlog normally, of course. The third
  52. option is the worst: they just see a hundred lines pasted into their backlog,
  53. which is already highly scorned behavior on most IRC channels. Only the GUI
  54. users come away from this happy, and on IRC they're in the minority.
  55. Some IRC clients (Matrix) have this feature today, but most Matrix users don't
  56. realize what a nuisance they're being on the chat. Here's what they see:
  57. ![](https://sr.ht/VOeY.png)
  58. And here's what I see:
  59. ![](https://sr.ht/HZ7Z.png)
  60. Conservative improvements built on top of existing IRC norms, such as [The
  61. Lounge](https://thelounge.chat/), are much better. Most people post images on
  62. IRC as URLs, which clients can do a quick HEAD request against and embed if the
  63. mimetype is appropriate:
  64. ![](https://sr.ht/9RsR.png)
  65. [^3]: Text user interface
  66. [^4]: IRC is over 30 years old and has barely changed since - so using unmaintained or barely-maintained clients is not entirely uncommon nor wrong.
  67. For most of these features, I think that people who have and think they need
  68. them are in fact unhappier for having them. What are some of the most common
  69. complaints from Slack users et al? "It's distracting." "It's hard to keep up
  70. with what people said while I was away." "Threads get too long and hard to
  71. understand." Does any of this sound familiar? Most of these problems are caused
  72. by or exacerbated by features which are missing from IRC. It's distracting
  73. because your colleagues are posting gifs all day. It's hard to keep up with
  74. because the infinite backlog encourages a culture of catching up rather than
  75. setting the expectation that conversations are ephemeral[^5]. Long conversations
  76. shouldn't be organized into threads, but moved into email or another medium more
  77. suitable for that purpose.
  78. [^5]: Many people have bouncers which allow them to catch up the last few lines, and keep logs which they can reference later if necessary. This is nice to have but adds enough friction to keep the expectation that discussions are ephemeral, which has a positive effect on IRC culture.
  79. None of this even considers what *is* good about IRC. It's a series of
  80. decentralized networks built on the shoulders of volunteers. It's venerable and
  81. well-supported with hundreds of client and server implementations. You can
  82. connect to IRC manually using telnet and have a pretty good user experience!
  83. Accordingly, [a working IRC bot can be written in about 2
  84. minutes][irc-slack-bot-comparison]. No one is trying to monetize you on IRC.
  85. It's free, in both meanings, and nothing which has come since has presented a
  86. compelling alternative. I've used IRC all day, every day for over ten years, and
  87. that's not even half of IRC's lifetime. It's outlived everything else by years
  88. and years, and it's not going anywhere soon.
  89. [irc-slack-bot-comparison]: https://drewdevault.com/2018/03/10/How-to-write-an-IRC-bot.html
  90. In summary, I like IRC the way it is. It has problems which we ought to address,
  91. but many people focus on the wrong problems. The culture that it fosters is good
  92. and worth preserving, even at the expense of the features users of other
  93. platforms demand - or those users themselves.
  94. ---
  95. P.S. A friend pointed out that the migration of non-hackers away from IRC is
  96. like a reverse [Eternal September][eternal-september], which sounds *great* 😉
  97. [eternal-september]: https://en.wikipedia.org/wiki/Eternal_September