About / Origin

About Slirc

Keep the parts of Slack that help conversation, lose the weight, and put IRC underneath it.

Slack's interaction model on top of IRC. That was the whole idea.

It started on a Friday

I met three friends at Lokaalhost:22. We spent a few hours comparing agentic workflows, sharing tools, challenging ideas, and leaving with more energy than we arrived with.

I wanted that conversation to continue. Signal did not work because one person was not there. WhatsApp was full of unrelated groups, tied to Meta, and easy to ignore. Slack had reactions, GIFs, and threads, but also a large Electron client, a short free-history window, and another subscription waiting down the road.

We all use terminals. Why not IRC?

My earliest memories of talking to people online are BBSs and IRC. IRC has survived for decades because it is small, open, and good at moving messages between people. Servers once ran on machines far weaker than a cheap VPS today.

I also tried Campfire. It was closer in spirit, but still larger than what I wanted. I wanted the useful shape of Slack with IRC doing the actual work.

Slack where useful, IRC everywhere else

The web app handles images, videos, link previews, reactions, notifications, direct messages, and threads. Underneath, the conversation remains IRC.

That distinction matters. Open Slirc in Senpai, mIRC, or another IRC client and the channel still makes sense. An image becomes a URL. A thread becomes another channel. Nothing depends on one interface understanding a private format.

The main client is a PWA. Save it to a phone and it behaves like an installed app without an app store or a large native download. Phone performance is not a fallback. It is the standard.

A deliberately small architecture.

Slirc uses Bun, Hono, Alpine.js, SQLite, and Ergo. Ergo owns IRC accounts, channels, permissions, and chat history. The app keeps the metadata needed for profiles, invites, reactions, uploads, and notifications.

I chose tools I can understand and operate myself. Small does not mean crude. It means fewer moving pieces, lower memory use, and less work when something breaks.

The resource difference is measurable. See Campfire vs Slirc for the current numbers.

Channels and access

Anyone can read the public channels #open-chat and #help. Posting requires an account.

Open channels are available to registered members. Invite-only channels stay hidden until someone invites you. Email is the front door: existing members receive a magic link, while new members add their name and verify afterward.

IRC still enforces the channel boundaries. Slirc adds a clearer way to use them.

Threads that remain IRC.

Threads were the interesting constraint. How do you isolate one discussion without inventing something ordinary IRC clients cannot read?

A Slirc thread is a channel linked to its opening message. The app presents it as a focused conversation. An IRC client presents it as another room. Both are true.

That pattern guides the rest of the product: improve the interface without replacing the protocol.

Formatting and media.

Messages support the formatting I use: bold, emphasis, inline code, and fenced code blocks with syntax highlighting. Images and videos upload from the composer. YouTube, GIFs, and Open Graph links get previews.

Those enhancements degrade into readable text and URLs outside the PWA. There is no hidden document format to decode.

Editing without pretending

Messages can be edited and deleted in the app. IRC history does not disappear from every client merely because the PWA hides an old copy, so Slirc does not promise that it does.

That compromise is worth stating plainly. Modern controls are useful, but IRC remains the source of truth.

Why the .org

I bought slirc.org because I want this to become something other people can run. Host it yourself, keep your data, and contribute fixes back. A hosted version may make sense too, because convenience is worth paying for even when the underlying software is available.

The first useful version took a couple of days and a few dollars in model credits. The harder part is not producing code. It is deciding what belongs, what stays understandable in IRC, and what should be removed.

That is still the work.