Skip to content

You Know What I Did This Summer

I started this post over a month ago with the line, "It's been a while since I've posted..." and then spiraled into an avoiding-writing situation. Anyway, pulling the bandaid off: for the past two months, I've been writing an IRC server.

I've never really implemented software against a standard before. IRC is supposed to be dead-simple, so I figured I'd start there. It's also social technology that people have augmented with extensions, so I figured it would be a great testbed for designing software with experimentation in mind!

Motivation

One of the final tasks I outlined for the Helical work was to instrument existing software for experimentation. The idea was that we'd take the formalism we'd designed and then apply to a real-world research study.

What I've written here is a bit of a retrospective and a bit of journaling; there's a big part of my psyche that believes this work is a failure, but I'm also someone who generally believes I'm a failing failure who does nothing but fail. I'm sure many of my peers feel the same about their own work (higher ed is filled with people who are unkind to themselves), but would actively find ways to reframe this "failure" as valued knowledge generation. Basically: the following may be ramblings of a depressed person.

While working on instrumenting a real-world piece of software, the reality of what that meant led me to the following realizations:

  1. Most of the interventions people actually do are quite simple. I think there's a bit of a feedback loop here: because most social software has limited interventional capabilities and researchers need to answer questions now, the research questions themselves tend to reflect these limitations. I knew some version of this going into the Helical project, but it became more salient with time.

  2. Identifying novel intervention points is very hard. It requires expertise in the software itself and broad knowledge of the kinds of hypotheses people test on the software (either as an object of inquiry itself or as a platform for data collection). This is a big ask.

    • Reading others' code is hard. I remember when I originally proposed Moodle as the platform to instrument and a colleague asked me if I really expected any graduate students to be able to read PHP. Rude, but maybe also fair? Legacy software is big, messy, and complex because the world is big, messy, and complex. Trying to understand a code base that isn't yours is hard enough when you are reading in a language you think you know and substantially more challenging when reading in a language that you definitely don't know.1

    • Most computer science students aren't trained in empirical methods or scientific reasoning.2 Also, water is wet. But seriously, this project has made the difference between "computational thinking" and "scientific thinking" quite salient for me.

  3. The politics of experimentation on sociotechnical systems has only gotten worse. While there are large-scale experiments done in e.g., systems research, there tend to be very carefully design testbeds and methods for data collection. That is, there isn't really any software to instrument. Social software is a better target — and was my original target anyway — but commercial software has gotten even more closed-off since I first wrote this grant proposal and there are real trust issues that are frankly demotivating for me personally.

A lot of things have changed since this grant was first awarded. I don't need to go into them; we've all lived it. That said, two years ago I thought we had some good momentum around the Mastodon privacy policy work, but I wasn't able to coax that into results.

This past June I started thinking about a different approach: what if we had a experimentation-first de novo implementation of an existing technology? After all, for software like Mastodon, the real way to integrate experimentation would be to have ActivityPub support for it.

I also got to thinking about the current RAM shortage and how much more expensive computing has become. I wanted something I could dogfood with my friends that had a small footprint. This is how I came to look backwards in time and land on writing an IRC server implementation.

Interestingly, the original IRC RFC predates the formation of the W3C by about a year!

The plan

Basic Server Implementation

I'm writing this post now as I've just refactored my code to handle server-server communication. The rough outline of work I've been following looks like this:

  • [x] Set up the main server loop to manage reading and writing over TCP.
    • [x] Decide how to handle multiple connections/concurrency.
    • [x] Test successful interleaving of messages from different multiple clients on the same machine and spread over different machines on my home network.
  • [x] Parse supported messages into an internal representation
  • [x] Design and implement internal representation and correct external formatting of error messages and stnadard replies
  • [x] Implement basic client functionality
    • [x] Handle client registration, channel creation and modes, channel and client messaging, and gracefully exit.
    • [x] Test using telnet (manual construction of messages).
    • [x] Test with an existing client.
      • [x] Hexchat
      • [ ] ICQ
  • [x] Finish remaining client functionality
  • [ ] Implement basic server-server functionality
    • [x] Server registration
    • [ ] Client mesage forwarding
  • [ ] Finish server-server functionality
    • [ ] Test multiple server connections

Basic Server Setup

I'm at a point now where I could set up one server at home for at-home communication between me, my partner, and any guests. My partner was thinking about implementing a web-based client that would then be accessible through our tailscale set up. I'd eventually like to replace our tailscle setup with headscale, but will save that for a future funemployment project.

Documentation/Tutorial

My code is currently hosted on my at-home Gitlab server, but I will likely open source it as a reference implementation in the future. My main hesitation for doing so is that I'd like to write up a self-guided tutorial on writing your own server, based on what I learned in this process. My goal is to write "assignments" that take about one hour per day to complete. I'd like them to be fun, thought-provoking, and for them to inspire someone who doesn't think of themself as a systems person to try their hand at writing some cool systemsy software.

Through the development process, I've been keeping a log of the approaches I've taken and changes I've made. I like the design choices I've made, but as always they are not without tradeoffs! I happen to have chosen to write this project in Rust; another language would likely lead to different choices.

I'd note that I am not a networking person! To systems people I'm either a stats person or a PL person. To PL people I do empirical research with a systems-y flavor. To stats people I'm an odd-duck wannabe who cares about weird minutae. It's my hope that my interdisciplinary perspective and relative lack of expertise makes this project more accessible to non-experts, not less.

Instrumentation

I plan to work on instrumentation in parallel with documentation. Since I'll be doing more explaining when writing out the tutorial, I figured I'd probably be in a good headspace to think about interventions and different design choices. I've made notes in my development log about future moderation considerations or architectural changes I'd need to support treatment assignment, but have tried to stay focused on really interrogating and understanding what's going on in the specification.

Comparisons with Existing Software

I hope my motivation for writing this software myself is clear: it allows me to viscerally understand the protocol and its capabilities in a way that just reading others' code cannot. That said, it would be irresponsible of me to not consider existing implementations! My undergraduate degree is, after all, in English Literature — I look forward to applying my close reading skills to code and interrogating different design descisions!

Finally, in some of my searches for more information about different commands, I came across an existing IRC project for educational purposes (and wish I'd come across this sooner)! I haven't yet looked at their code base, but will definitely include in my comparison.

Interested in participating?

Right now I'm working on this project solo, which is typically less fun for me than working with others. My current thoughts on possible collaborations:

Contribution/Collaboration type Level of interest from me Justification
1 Reference server implementation in Rust Low Since making mistakes and mistunderstanding things is important for the educational materials I'm developing, I'm less interested in contributions to the main code base, unless you were to commit to logging your decision/design process.
2 Working through tutorials High It would be great to have some continuous feedback from a potential user!
3 Running the reference software Medium This is mostly a medium because testing is a slog and with the restrictions of (1), I feel like it would be more of a burden for the other party.
4 Interventional stuff High Whether it's posting your opinon on Mastodon, sharing resources you like, keep abreast of the projects current interventional capabilities, or outright contributing, I'm happy and not at all desperate to have any kind of dialogue about this topic.

Please reach out over email or hci.social. If we don't already know each other, I'd like to have a synchronous call to make sure you aren't a bot.

  1. In some ways, LLMs have made this easier (or at least easier to pass the part of my interview that dealt with navigating a code base) — it's a lot easier to find the thing you're looking for now. However, the old process of finding (e.g., greping for terms and looking at files) had a point — it helped you build a mental mode of the code base, which it turns out is necessary for the task! ↩

  2. Every student who has worked with me has gotten some version of empirical methods/scientific reasoning training from me, but it still takes practice. I've worked with exactly one student on this project who had a laboratory science background and it made a huge difference in their ability to reason about the kinds of experiments people do run, can run, or might want to run on different platforms. ↩

Comments