FIRC: My Journey Toward a Federated IRC Server

Hey everyone! Sarah here. It's been a while since I've given a deep dive into another passion project, FIRC – the Federated IRC Server. Today, I want to pull back the curtain on where we are, the challenges we've tackled, and the ambitious vision I have for FIRC.

From Scratch to a Solid Core: Where FIRC Stands Today

For those just joining the journey, FIRC started with a simple, audacious goal: to build a modern, robust IRC server entirely from scratch in Go. No inheriting decades of C code, no patching old vulnerabilities – just a clean, opinionated implementation.

And I'm thrilled to say, we've come a long way!

Right now, FIRC is a fully functional, barebones IRC server. It handles:

  • Client Connections: Users can connect, set their NICK, and identify with USER.
  • Channels: Users can JOIN and PART channels, set TOPICs, and PRIVMSG other users or channels.
  • Basic Modes: We've implemented crucial channel modes like +t (topic lock) and the ability for channel operators (+o) to manage these.
  • Authentication: NICKSERV for account registration and login, CHANSERV for channel registration, and even OPERSERV for server administrators are all up and running, leveraging a SQLite backend for persistence.
  • Robust Architecture: The entire codebase is designed with modularity in mind, using Go's concurrency features to handle multiple clients efficiently. We've separated concerns into client, channel, db, config, commands, and services packages, making it a joy to work on (most of the time!).

We've focused on stability, correctness, and laying a rock-solid foundation. This isn't just "another IRC server"; it's my IRC server, built with a purpose.

Beyond IRC: The True Vision for FIRC – Federated Chat

Here's where things get really exciting, and where the "F" in FIRC truly shines: FIRC isn't just about being an IRC server; it's about being a bridge to the federated web.

My ultimate goal is to evolve FIRC into a federated chat platform that leverages the robustness and widespread client support of IRC, but can communicate seamlessly with the broader ActivityPub based network.

The Next Frontier: Building the Federation Layer

This vision means our next major phase is integrating ActivityPub. This isn't a small task, but the groundwork we've laid makes it possible. We'll be focusing on:

  • Identity Mapping: Translating IRC NICKs, USERs, and HOSTs into ActivityPub Actor IDs (@user@instance.name) and vice-versa. The hostmask (Nick!User@Host) will be critical here for representing remote federated users.
  • Outbound ActivityPub: When an IRC user sends a PRIVMSG to a federated channel or user, FIRC needs to generate the correct ActivityPub JSON, sign it, and push it to the remote server's "inbox."
  • Inbound ActivityPub: FIRC will need an HTTP endpoint to receive ActivityPub "Activities" (like Create, Follow, Undo) from other servers, translating them into IRC events (JOIN, PART, PRIVMSG).
  • Channel Federation: Implementing the logic for an FIRC channel to be "followed" by remote ActivityPub groups, and vice versa.
  • Discovery: Ensuring /LIST can discover channels across the fediverse and /WHOIS can pull information for federated users.

This is where the rubber meets the road. FIRC will need to be configured with its own public domain, handle HTTPS, and act as a full-fledged ActivityPub server, while still being an IRC server.

It's a challenge I'm incredibly excited about. The potential to create a truly open, interconnected chat experience using the best of both worlds is immense.

Stay tuned, and if you're interested in decentralized tech, IRC, or Go, consider following the project! Your feedback and ideas are always welcome.

Happy forging,
Sarah