IRC Client Daemon: 2.1.0

Added by David Demelier 6 months ago

Irccd 2.1.0 is now available.

For a full list of changes, see the changes in 2.1.0.

Some highlights:



SSL has been added as an experimental feature in the irccd ip transports.

To enable it on a irccd transport

type = ip
port = 7777
ssl = true
key = "path-to-private.key" 
certificate = "path-to-certificate.key" 

To enable it in irccdctl

type = ip
host =
ssl = true


Authentication is also now supported for both unix and ip types.

In irccd configuration:

# as before
password = foo

In irccdctl configuration:

# as before
password = foo

New plugin-config command

A new irccdctl plugin-config has been added, it can configure a plugin at runtime.

With only one argument:

$ irccdctl plugin-config plugin
max-list-columns : 80
max-list-lines   : 3

With two arguments:

$ irccdctl plugin-config plugin max-list-columns

With three arguments:

$ irccdctl plugin-config plugin max-list-lines 5
markand@kiwi ~ $ irccdctl plugin-config plugin
max-list-columns : 80
max-list-lines   : 5


Irccdctl now supports aliases to define custom list of commands.

hello = ( "server-message", "%0", "%1", "hello world !!!" )
goodbye = ( "server-message", "%0", "%1", "goodbye !!! :(" )

unload = ( "plugin-unload", "%0" )
load = ( "plugin-load", "%0" )

This example configure two new aliases: cycle and full-reload. They use placeholders to pass arguments at runtime

$ irccdctl cycle freenode #test
$ irccdctl full-reload ask

IRC Client Daemon: Absolute paths forbidden in some CMake options

Added by David Demelier about 1 year ago

Starting with revision r101 (and future 2.1 version), irccd now completely disallow absolute paths for the following options:



It is highly recommended to make relocatable software. But what does that mean really? It means that wherever the application is installed, you can safely move it to an another location without recompiling it and the application can still run. The only requirement is to keep the same hierarchy.

In the case of irccd, it uses the following defaults on Unix:

  • WITH_BINDIR: bin/
  • WITH_CACHEDIR: var/irccd/
  • WITH_CONFDIR: etc/
  • WITH_DATADIR: share/irccd/
  • WITH_PLUGINDIR: share/irccd/plugins/

Thus, when irccd is installed in bin/ directory, it knows how to go to the configuration directory by going upward a directory and then in etc/ directory. This is done by retrieving the executable path. This means you can safely install irccd into any directory and then move it somewhere else.


cmake . -DCMAKE_INSTALL_PREFIX=/tmp/irccd-test
make install

Now, /tmp/irccd-test/ is filled with bin/, etc/ and such. I can safely move /tmp/irccd-test/ somewhere else, irccd will still knows where to locate its directories.

Why disallowing absolute paths

Irccd's CMake process builds the project into a fake root directory, in ${CMAKE_BINARY_DIR}/fakeroot. This makes easier to test irccd without installing it as the fake root directory already simulates the installed project. It makes also much easier for packagers to determine the installed files as they are exactly the same upon installed.

But to use this fakeroot directory, users must not use absolute paths as CMake options are appended to it, thus, setting WITH_BINDIR to C:/Irccd/bin will define the path to ${CMAKE_BINARY_DIR}/fakeroot/C:/Irccd/bin which is indeed invalid.

To fix this, a warning was shown telling that absolute paths are not recommended and fakeroot was disabled in this case, ending with a lot of conditionals in CMake, polluting the readability.

As it's not usually needed to change these directories and to facilitate irccd's development, it's not possible to make them absolute anymore.

But I want to mix / and /usr/local!

While I think you should keep everything belong to the CMAKE_INSTALL_PREFIX variable, it's still possible to tweak the installation to use different parent directories.

cmake . -DCMAKE_INSTALL_PREFIX=/ -DWITH_BINDIR=usr/local/bin -DWITH_CONFDIR=etc -DWITH_DATADIR=usr/local/share -DWITH_CACHEDIR=var/irccd -DWITH_PLUGINDIR=usr/local/share/irccd/plugins

With that invocation, you'll get irccd installed like this:

  • WITH_BINDIR: /usr/local/bin/irccd(ctl)
  • WITH_DATADIR: /usr/local/share/irccd
  • WITH_CONFDIR: /etc/irccd(ctl).conf
  • WITH_CACHEDIR: /var/irccd
  • WITH_PLUGINDIR: /usr/local/share/irccd/plugins

Incoming improvements

Anyway, these CMake options only alter defaults and a new feature to include more paths in the configuration file will be added soon, see #470.

IRC Client Daemon: Irccd 3.0 will be written in Java (2 comments)

Added by David Demelier over 1 year ago


It's been a long time I was thinking about leaving C++. The problem with C++ is that it's a language from the past. It's important nowadays to move towards new technologies such as Node.js, Java 8, Rust and such.

All these new technologies facilitate deployment, collaboration and evolving features.

There are much more people who know these languages than C++. I've written C++ for several years and now I think I should just jump on something else to improve my skills.

Why Java?

I know Java very well as it was one of my preferred language at school and in my internships.

Java is performant, easy, convenient and portable. With Java, no problems: write once, run everywhere.

I already checked the IRC library and there is a good one called PircBot which is also opensource.


I think irccd 3.0 will not be released after at least seven years. Probably in 2023. Irccd consists of somewhat 18000 lines of code at this time. However as Java require less code, the port won't be so difficult.

1 2 3 (1-10/27)

Also available in: Atom