/* 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. */