/* Have been playing with ircu+asuka in recent time. Had a small glitch getting it to work properly in a chroot under OpenBSD - when I tried, it just respawned/reloaded itself repeatedly and continuously, and the only way to stop it was to move the executable:

$ sudo mv ircd ircd.broken.dammit

This turned out to be because it wanted a /dev/null in the chroot with it.

Hope this helps someone. Probably me, when I forget and try to set another one up. */

/* Thoughts on ircd design:

The ircd purely provides connection services and channels/nicks of arbitrary lengths; the rest is all done by producing an ircd.conf that consists of mode prototypes for users and channels, and predicate-chains hanging off events that determine whether that event is allowed to proceed or not. These would presumably have to have (1) some idea of global state and (2) be precompiled for speed to some extent. Channel/user modes are either 1- or 2-ary predicates (chanmodes +o and +b are 2-ary, for example; +i and +m are 1-ary). There would have to be other predicates too (such as user on channel):

(mode chan +o nick:nick)
(mode chan +n)
(mode chan +m)
(rule nick privmsg channel:channel msg (or (and (chan+n channel) (user-on nick channel) (not (chan+m channel))) ... ))

For bonus points, linked ircds should hash their predicates (that would probably sound obscene if I cared) and exchange hashes to make sure that they have compatible predicates.

This looks intriguing, but I think if I require server admins / network admins to learn a real language to use the ircd, then I will have no users; I also suspect it's gratuitous overkill. Sigh.

For extra bonus points, solve the problem of storing the distributed persistent state without using that fecking awful services kludge.

I will never have the motivation to write an ircd. */