– IRC News

All about Internet Relay Chat

Interview with QuakeNet staff

Today, we’re proud to present you an interview conducted with QuakeNets Head of Public Relations Joe “meeb” Harris.

QuakeNet is the worlds largest IRC network and caters mostly – but not exclusively – to gamers.

Without further ado, below are the questions and answers:

First, please introduce yourselves to our readers!

Hi! I’m Joe “meeb” Harris. I’m currently the head of public relations for QuakeNet, which is largest IRC network in the world and has been since around about the end of 2003. I’ve been an avid IRC user for nearly 10 years, and joined the QuakeNet staff around 8 years ago as a member of the network support team, moving on to joining the public relations and development teams later. I replaced Ferg when he found his time limited as head of the public relations team about 4 years ago, since then I’ve overseen the interaction of QuakeNet with external organisations such as game studios who run regular popular events including developer chats and assisting gaming groups.

QuakeNet, where did it all begin?

QuakeNet was formed 13 years ago by Oli and Garfield (both of which can still be found occasionally lurking in the dark recesses of the network!) who wanted to help organise games of QuakeWorld online. It quickly grew with the initial surge of online Quakers and became a central part of the deathmatch-organising scene.

Later on it developed into a more general network, but it still retains a massively strong gaming core.

How did it grow to where it is today, still being the worlds largest IRC network after 13 years in existence?

Entirely by word of mouth and third party advertising, as a completely non-profit organisation we have no resources to promote ourselves really other than to offer services that we think people will want to use! We must have done something right, given we’re still pretty popular.

What are your duties as staffers and how do they compare to those on smaller networks?

The staff on QuakeNet is divided up into multiple workgroups, each tasked with oversight of a particular area and given the authority to autonomously cover one aspect of the network operation. The larger groups cover network support, development, public relations, security, operations and human resources. There are multiple sub-groups under these such as the tutorial group, web development, script support and so on. Each group has a group leader, and the group leaders form another group. All groups work under the oversight of the operations team which consists of the administrators of the physical servers and oversee the core network decisions.

Most users would only interact with the user-facing groups, such as our excellent network support team headed up by the veteran “beard” Bazerka, but that’s really just the tip of the iceberg in terms of what happens behind the scenes. Members of staff are welcome to apply and join multiple groups (for example I’m an active member of three groups, and a somewhat idle member of another two); we have excellent volunteers actively working on all aspects of developing QuakeNet.

How can one support the network?

Pretty simply, by becoming an active user on the network! IRC needs you! If you work for an ISP or other provider with a serious stack of spare hardware you can apply to assist QuakeNet with an extra server and join other excellent sponsors such as Id software, port80, Multiplay (and many others) in providing the stable platform our network is based on. If you have a lot of spare time, you can contribute by joining the ranks of our staff and helping the network grow even further. You don’t get paid, but there’s a lovely warm feeling from helping hundreds of thousands of users communicate better (and you get to stroke snailbot).

I’m sure many users, newbies and veterans alike, would love to become staff on QuakeNet – any word of advice how they could accomplish that?

I’m not ashamed to say that we’re extremely picky, we have what can only be described as triple-stage rigorous hiring procedure. Anyone can apply via a link on our website, and their application is processed by the HR team. If your application matches the base requirements and there’s an opening in the team you are applying for you’ll get a one-on-one interview followed by an extensive trial in the group you’re interested in joining. After that, there’s a full group vote to accept you as a member.

You shouldn’t be put off by this, if you are accepted into QuakeNet staff you become a member of a dynamic network of a hundred or so active people from all over the world and tasked with key responsibilities and representing QuakeNet. Once you’re in the staff you can also apply to join other groups that you think you can contribute to, further expanding your role in the organisation of you want to.

Late last year, you introduced a server sponsored by id Software – how did that collaboration get started?

Id Software developers have made fleeting appearances on QuakeNet for many years, and recently started making a more regular home. This culminated with the launch of QuakeLive which has a permanent channel on QuakeNet since the start of the beta, where the beta testers could directly relay feedback to the developers. We opened a dialogue with some of the developers as we do with most important organisations on QuakeNet to see if we could assist in any way. They generously offered to host a client server but were unable to provide the direct resources to oversee the new server (it can take quite a lot of time to learn everything from the ground up to run a popular client server on QuakeNet, as well as ongoing responsibilities to keep it maintained). We reached an agreement where some existing administrators on QuakeNet would take on some of the responsibility of maintaining the server and they would provide the physical hardware and connection, we also welcomed SyncError as the primary operator for the Id Software server onto the QuakeNet staff.

This has been working very well to date, and we are happy to have Id Software as one of our core US client server providers along with Gameservers and Velocity.

Most software you create for the network (qwebirc, snircd, operserv) is released as open-source – why not the rest of the services, like Q and S for example?

This isn’t anything nefarious at all, I’m sure most of the staff on the QuakeNet development team would agree that we would happily release almost everything if not all our code as open source projects. As you can imagine the non-linear structure of a purely volunteer organisation such as QuakeNet can make some projects a bit complex to keep track of. With the open source examples you list, qwebirc is primarily developed by probably our most active developer, slug, and it’s entirely up to him how it’s licensed. Snircd is a fork based on the excellent Undernet IRC daemon (IRCd) and we are more than happy to provide the source.

The repositories not yet public are currently closed for a very simple reason, they’re not stand-alone services but modular services for our outstanding service platform / framework “newserv”, you can forgive the less than vibrant name given it’s happily hosting almost all of our current services! Newserv is primarily developed by one of our other lead developers, splidge, with contributions from other staff members. We of course need the complete sign off from all the developers involved to release a project, some have since resigned their positions on QuakeNet (and hard to track down), some are still deciding. This makes it pointless to release (for example) the sourcecode for the Spamscan module given it serves no use what so ever to anyone without the base to run it off.

Personally I am confident that eventually the remainder of our currently private code will be publicly available at some point, although don’t assume anything as opinions can change over time!

Recently, a large open-source focused network introduced the ability to have user-connections encrypted with SSL – are there any plans to do so on QuakeNet?

It is currently under discussion, but there hasn’t been a great deal of movement in the SSL area if I’m honest. I would suspect that eventually we will introduce an SSL option, but it’s not likely in the short term. IRC is typically regarded as a public medium so SSL encrypted client connections have a limited use at best. This might be pushed up the task list depending on external circumstances such as regional governmental internet monitoring, but I wouldn’t expect it quickly on QuakeNet. Generally the other use for SSL (certifying the IRC server is who it says it is) is negated by most other networks not deploying certificates from commercial authorities (and understandably so) – this again makes IRC over SSL less useful in general.

Many IRCds cloak userhosts (or parts of them) even without registering – why isn’t this done on QuakeNet?

We take user privacy seriously on Quakenet, and we provide excellent and easy to use functionality to mask your host if you choose to. We also allow full access from TOR exit nodes if you wish to chat truly anonymously, but we believe that this is a choice. You can easily configure your IRC client to mask your host as soon as you connect if you wish which provides the same functionality as other networks, we just don’t force the decision on you.

This allows our users some freedom to use custom vanity hosts for bouncers and bots as well as channel administrators to more accurately keep their channels in order by banning troublesome ISPs.

Q and its help is only available in english – do you have plans to change that?

Q actually supports many languages! This was a core feature of the “new” Q, codenamed Q9, that was deployed some two years ago (again mostly by splidge). We had some issues sourcing high quality translations for some of the Q messages, and it was decided to not delay the launch just to wait for the extra languages. I’m sure they’ll arrive at some point.

IRC can be a scary and to some extent dangerous place for unsuspecting users – what safety tips can you give them?

Much the same as most semi-anonymous online forums, don’t give away any personal information (at all!), don’t provoke confrontation, keep online and offline communication separate. If you do encounter any serious abusive behaviour you can contact the network support team in #help who will assist you with any problems, we have even filed regional police reports in extreme cases to help protect our users and QuakeNet.

If you could change one thing in the way IRC works – what would that be?

I would probably build in redundant links for clients and servers, resulting in a dramatically less violent ‘netsplit’. If I was designing the protocol now I’d include more common features expected in 2010 such as a standard for transmitting general media (avatars? streaming video? who knows). And snails, everything needs more snails.

There have been many polls and forum topics about a decline of IRC – what is your opinion on that and where do you think is IRC heading in the long term?

It’s natural that certain mediums become more popular while others decline. Given that IRC is a pure text group chat (as the popular bash quote says, it’s basically just multiplayer notepad) I think it’s a testament to the big IRC networks that they’ve been around for many years and still with active user bases. We tend not to worry about the physical number of users dropping off a bit from their peak in the early 2000′s, the users who do remain are extremely numerous and dedicated.

In the future, I think IRC still holds a unique place. No-where else provides the ease of collaborative communication online in an effortless medium with very well established clients and user management systems. The novice user might have replaced their IRC usage with newer web-based services or flashier methods of realtime messaging, but there still remains very few places on the internet where you can jump straight into such a massive and active community of people. You don’t really see many 50-person MSN chats.

We’ve recently had a substantial growth in one area of QuakeNet thanks to our simple yet powerful qwebirc web-based IRC client which seems to have introduced a new group of users to IRC, as well as provide a popular client being utilised by many other networks including a couple of the other “big four” IRC networks. (you can check pop directly onto QuakeNet with just a JavaScript-enabled browser at and if you run your own IRC network you can get the source code for the client at In summary, we’re pretty positive about the future.

What do you use IRC for when you’re not actively “on duty”?

Mostly chatting with friends, ex-collegues and sharing the latest memes (how do you think they spread so fast, it’s not because of ‘microblogging’!). It’s only really the user-facing staff members that have to take shifts and be on-duty as such, the rest of the staff are usually available for network based discussion whenever they are online in a relaxed manner.

What can users expect feature-wise in the future on QuakeNet? What plans do you have for the network?

We have some light hearted fun planned for the near future, and we’re actively in discussion with several organisations to bring more developer-orientated live events to QuakeNet. We’re constantly rolling out improved versions of existing services as well as introducing brand new features, admittedly largely behind the scenes to the average user. If you notice a dramatic decline in irritating spam on the network, then it’s us doing something new!

In the timetabled future we have a new release of our IRCd in the works which merges in many of the changes released by the IRCu team over at Undernet as well as adding some more QuakeNet-specific features, and upgrades to some of our channel services. The new IRCd will contain some new features to help combat some current annoyances on QuakeNet, such as unsolicited private queries.

Thank you for the interview, do you have any parting words for our readers?

No problem! As some parting words I’d probably suggest you try embedding a qwebirc chat frame into your clan site or blog, it’s awesome. Oh, and remember to send some love to molluscs. Pop onto QuakeNet and say hello! You can find the PR team in #QuakeNet.

Thanks for reading,


Thanks go to meeb for the awesome interview & QuakeNet for generally being great :) Live long & prosper!

  Copyright secured by Digiprove

Interview with Anope project leader chaz

IRC services are a software that enables IRC networks to provide channel and nickname registration, or, as Wikipedia puts it: “Services are automated bots with special status which are generally used to provide users with access with certain privileges and protection”.

One of the more well-known packages you can use for such a task is called Anope which i’m sure you’ve already heard about and today i’ve interviewed the leader of the project, Charles “chaz” Kingsley.

Hello :) Please introduce yourself to our readers.

Hi there,

My name is Charles Kingsley and I’m the project lead for Anope IRC Services and also a contributing Network Administrator on the Teranova IRC Network and IRC Operator on Chatspike.

In *real* life, I work as an IT Consultant designing and building systems for businesses and educational institutions centric to the safe and secure ‘always’ available system model.

When did you begin using IRC and what was your “path” on it?

Phew, this was a long time ago now..

I started on a java chat site running “Chatspace” software some time back in the late 90′s where dialup was the way of life and soon developed an interest in hacking mIRC to pieces and making it do things it didn’t want to. (This of course required an offline IRC Server to play with as dialup back then was quota’d per month!)

I then found myself on Dalnet helping out in various channels before discovering that there was more to IRC than a single network. I can’t quite recall how but I ended up on Dragonlynk / IRCXP and was given my first oline around 1998/2000-ish and ‘taught’ how life was on a modified Bahamut.

As time went on, some of us from Dragonlynk/IRCXP spurred off and created our own little network of ‘home’ boxes connected together using free services fondly referred to as “no-ip” net. – This the very foundations of what Teranova is today.

During this time, I also flirted with positions on other networks; often working with the people there to strengthen their position, improve security and try and impart a professional style of working, something I found at the time IRC lacked.

I found myself on the Anope IRC Network some time later having taken it upon myself to be ‘responsible’ for services on our network and a while after helping some folks out on there I was approached to join the then QA Team. Some time went past and as I found my feet I started picking away at things happening within the Team and increased my responsibilities until things went a little off the radar and the then original project lead left to progress his real life professional career and left someone else in charge. At this time I stepped up and took over running the ‘QA Team’ within Anope.

Some time later, leading up to our 1.8.0 stable release it was decided I would takeover the management of the team as our project lead had become engrossed in his studies at University and as I had (have) no life I was in a position to steer things forward.

That was almost 18 months ago and since then we’ve continued to go from strength to strength improving and refining our stable branch whilst rocketing ahead pioneering the roadmap for our development branch.

It’s been an exciting ride and continues to provide enough work for a team twice the size of the one we have so times are often tough but we’ll plod on and get on as well as we can. (*Hint, if you have skills or time (or both) please get in touch if you want to help).

How many people are working on Anope?

I am not someone who judges “work” based on code contribution so I will tell you that our team consists of 8 people, each with their own specialities, and each bringing their own contribution to the project.

Why did you feel the need to fork from Epona back then?

This was before my time but I can comment that based on my history lessons with Father Rob of the project him and dengel were maintaining a patchset for Epona (for Hostserv amongst other things) but that Lara (Epona Developer) vanished off of the face of the earth taking the coding repositories (with the most up to date patches), web presence etc with her which left a bit of a hole in the market.

Dengel and Rob at the time decided to start up Anope (epona backwards for those who hadn’t noticed) with their patch sets against the latest available release with the intention of checking this all back into Epona once Lara returned.

As time went on though, the amount of changes introduced made the application become less of a patch set and more of an overhaul so even once Lara returned to Epona so the project continued….

How much of the original codebase is still in Anope?

Phew, I have no idea, that’s a tough one.

It’s fair to say a large proportion has been altered over the years.

How much time did you put into the project and the support of it yet?

Now? I spend some hours each day I suppose reading #anope and answering if there are no nice support people around to answer the questions. I frequent the forums daily incase I’ve missed something not reported in #anope from the RSS feed and generally keep communications flowing between the team to see how we all are.

An important mention is that we are all volunteers with jobs and lives outside of Anope which is seldom understood when we tell people we simply do not have time to do x, y or z at this time.

Even though you probably heard this question over and over – when will Anope come with live SQL support?

Live SQL, yes, this is of course the big question coming from many people and for the sake of not wishing to commit to anything I can tell you it is roadmapped for 1.9.2 but this may slip as we’ve introduced a completely new database format already and in the interests of sharing the features and gaining feedback this may slip however we have taken some positive steps and have a working solution based on the stable (1.8) branch of Anope in LiveSQL mode in a large network at this time.

One of our team members has managed to build in LiveSQL into 1.9 for testing and review but at this time there is no agreed solution but we are looking at various methods of providing the flexibility without incurring too much of a CPU overhead.

More to come on this soon.

In the future, what can we expect from Anope?

Whatever people want to see.

We mostly are going off of our own steam creating features we *think* people want and fixing bugs etc but really the future is what everyone makes of it, the road map is deliberately short so we can include requests and ideas at every step.

Compared to other IRC services, Anope is…?

a solution for those who want to use it. I’m not someone who wishes to bad mouth or criticise other systems but we are simply responding to community requests for features and integrating our own experience and knowledge into providing a solution people want.

We’re fairly popular so we’re doing something right I reckon.

How can the community around Anope get involved and help you to evolve the services?

Well ……

We need translators for when we burn the existing language files carried forward into 1.9 from 1.8 as at the moment they are a limiting factor and can cause some stress if edited incorrectly.

We need multilingual supporters who wish to provide support on our forum (we will introduce international forums if these are necessary), and in specific geographical #anope.xx channels.

We need people to get stuck in and offer to test the software and contribute back their views and suggestions as well as providing information on bugs and glitches. We simply cannot test every single feature you may use on your network and in community spirit we could do with everyone helping everyone else.

Peer support is very important to a project like us; we’ve all asked questions someone else has thought was stupid at some point in our lives. We’re all human and working together is crucial.

If you could improve one thing in the IRC protocol, what would that be?

I don’t really have any improvements I can think off as we are able to do most of the things we want within Anope.

I am interested in meshing though, I can see that being particularly useful for geographically interlinked networks over different providers. This is something I do hope to see in the future.

Development aside, what do you use IRC for in your leisure time and which networks do you frequent?

Before, during, & I’m sure after Anope I’ll continue helping people with their computer problems and otherwise assisting them with their use of IRC whilst being able to relax and chill out with my friends.

I frequent (home of Anope Support, and a network I have been with since day 1), and where I was today funnily enough asked to become an IRC Operator.

Two networks with very different atmosphere’s and I wouldn’t change either of them for the world.

I’ve also started to idle in the support channel on to see whether I can help out there but the folks over there have it pretty well wrapped up so I can just sit back and giggle at Phil and his abuse of global!

There are numerous topics, polls and postings about a possible decline of IRC – what do you think about that and where do you think is IRC heading in the long term?

Statistics are just numbers, people have this way of going completely against statistics and doing things we’d never expect so I do believe that taking these polls and postings with a grain of salt.

We’re seeing downloads increase, from my idling in InspIRCd’s support channel I also see the number of people being supported increasing so I don’t really see a decline in the uptake of new systems.

Thank you for the interview – do you have any last words to our readers?

Thanks for the opportunity as always, a pleasure assisting someone who actively contributes on our network.

I would like to thank our sponsors ( ) for their continued support with our project and also every single person who has ever helped Anope be it by downloading it, reporting/fixing a bug or just by taking part in our support system and we would welcome more of you :)

Hope you all have a nice week ahead.

Many thanks go to chaz for taking the time for this interview!

DALnet releases Bahamut IRCd 1.8.6

After more than 2 years of silence the DALnet Coding Team released a new version of Bahamut, an IRCd mainly used on

First being released as version 1.8.5 there was a bugfix-release shortly thereafter as a bug has been found in channelmode +c which sometimes not only prevented control-characters as bold and underlined being sent but also stripped legitimate messages that contained certain arabic and hebrew characters.

We took the time to ask Epiphani – the Coding Teams Team-Leader – a few question about his IRCd and the history of it:

- The last release, 1.8.4, was over 2 years ago – why did it take so long for 1.8.5 (and now 1.8.6) to be released?

It’s mostly been two reasons:

1. We didn’t really have a lot of minor things we wanted to work on.

Bahamut has been stable and effective for several years, and while there is enhancements that we’d like to implement, those enhancements are more major changes than they are small updates.

We did have a few fixes come through the pipe, such as security fixes and minor other fixes (such as updated x64 support), and we decided to roll them into a patch release.

2. Life gets in the way of open source development sometimes.

At present, the team is mostly idle as life has started eating most of their time. I’ve had a few changes in my life recently that have allowed me to put more time into Bahamut once again, so I’m hoping we can revive some development.

We’ve also changed some of our processes (including a move from subversion to git) so we’re hoping to get more involvement from the community in the future.

- The list of changes introduced with this release does look small compared to the ones introduced with 1.8.4 – what, in your opinion, are the most important ones?

Mostly the security updates.

For example, we removed zlib from the distribution and made it an external dependency, due to security updates from the zlib people – we didn’t want to have to release every time zlib has an issue.

There were also a few fixes for “IP leaks” where hub IPs could be shown to normal users in certain edge cases.

- Are there any changes that are noticeable on the user side of things?

Nope, not in this release.

- When did the development on Bahamut start and why?

I believe the project kicked off sometime in late 1998, with the first public release in 1999. I can’t really remember, that was a good while ago.  :)

The Bahamut project came about due to some of the performance concerns around the former DALnet ircd, Dreamforge.

Back in 1999 DALnet was growing very fast, and the hardware we were running on wasn’t terribly fast.

We needed to be able to support over 6000 clients on a 250Mhz machine, and Dreamforge simply didn’t perform to those levels. Once we rolled out Bahamut, we started seeing much better performance.

I believe somewhere in 2001 we hit our record with around 45,000 clients on a single 900Mhz AMD Duron machine with 512 megs of ram.

- Is there anything you’d like to mention?

We’re always looking for contributors to Bahamut.

We have a wishlist of features, including ipv6 and other such things, that anyone is welcome to code up and provide patches for to the dalnet-src [at] mailing list.

We are mostly interested in people with the initiative to bounce ideas around on the mailing lists and go off and code!

The complete list of changes between 1.8.4 and 1.8.6 is below:

- Fixes for x64 – this is a combination of Kobi’s work and my own.
- Fixed m_part() and m_quit() to ignore part/quit reasons from squelched users.
- Fixed compiler errors with gcc4.
- Changed a debug message that could leak servers’ IPs to ADMIN_LEV. Thanks key!
- Fix configure tests for zlib removal.
- This patch is intended to mark SVSHOLDs as SBAN_SVSHOLD to stop them from being removed by a kill -HUP
- Fix several small issues where IPs would be displayed when they shouldnt be, from Kobi (kobi [at]
- Do not display uplink of ulined servers, from Kobi (kobi [at]
- Fix slight errors in m_who argument parsing, from kobi (kobi [at]
- Do not display warnings about juped servers attempting to commit, from Kobi (kobi [at]
- Fixed m_invite to honor umode +R and silence restrictions.
- Two small rwho fixes to option parsing, from Kobi (kobi [at]
- Add hooks for several events
- Remove zlib from the distribution – rely on the library provided by the system.
- Fix msg_has_ctrls() so it doesn’t block non-control characters.

Bahamut IRCd can be downloaded from here.

Thanks go to Epiphani for the short interview and the wants-to-stay-anonymous tipster for the tip! :)

Interview with the author of EPIC5

After being 5 years and 11 days in the making, there was the first production release of the ircII fork EPIC5, now being at version 1.0, in the end of December.

For readers that don’t know the project yet, the website explains a little of EPIC’s history:

EPIC is an irc client project. The EPIC software was forked from ircII-2.8.2 in fall 1994. There have been 5 generations of EPIC, of which the newest two (EPIC4 and EPIC5) are still supported and in development.

5 years and 11 days – What caused that kind of delay?

I became curious and messaged the author of EPIC, who goes by by the nick hop on IRC, and we agreed on an interview – read on below…

Please introduce yourself to our readers so they get an idea who you are. How did you get into programming in the first place?

I’m over 30 years old and I live in the USA.

I had never really programmed as a kid.  I had a commodore 64, but basic was pretty unsatisfying and assembly language hurt my brain too much.  When I went to university as a wannabe engineer, I learned about higher level languages like FORTRAN and really took to them instantly.  There was just something effortless I found about coding that I had not realized was there.

I had gotten addicted to irc in my freshman year in university, and by the middle of my sophomore year, I realized that I could start fixing all of the things about ircII that annoyed me.  So I taught myself C and dove in.  For the most part, epic is just a client that I maintain for my own benefit, and I am happy to share it with everybody else who is interested in it.  Even if there were not one other epic user in the entire world, I would still maintain it, if for no other reason than I’ll always need an irc client.  But there will always be epic users, and I hope to have the opportunity to build friendships with all who are willing someday. =)

Is EPIC actually a real acronym or “just” a backronym?

EPIC is a deliberate and malicious backronym. At the time, it was common for groups to come up with an acronym and then make up some retarded way to spell it out. For example, STAR might stand for “standing tall against racism” which is a fine and noble thing to do – but you know that they came up with “STAR” before they came up with what “STAR” should stand for.

So to make fun of groups like that, i had said we should do the same thing, so we came up with EPIC and then we threw out ideas for the most retarded over the top “meaning” for it. Alas, in the end, because of our lack of imagination, we came up with something retarded, but not retarded *enough* to be seen as satire.

Was there a specific reason to fork ircII back in 1994 and if so, which?

Back in 1994, there was really only one client being used, ircII, and they had a definite notion of controlling the users by limiting what the client could do. Some of us had gone off and formed the undernet and we were looking to expand the potential of irc, rather than keeping the status quo, so there was a slight culture clash when the maintainer of ircII (who is a perfectly upstanding gentleman, I must say here) reviewed my changes and found them generally unsuitable.  So for those of us who felt that we had new ideas, it fell to us to develop (and run) our own servers and clients.  And that’s pretty much what we ended up doing.

How many core developers are working on EPIC5 and how do you coordinate development?

It depends on what “core” means.  EPIC is two things — a core software client and a script pack that completes your experience.  As far as the core software goes, that’s pretty much a one-man-show, as everyone seems content to let me do what I do.  Sometimes people will help me for short periods of time on small projects, but it’s pretty much left to me to push things along.

There is more activity in the script world.  I try not to be a “Microsoft” where I want to dominate both the operating system and the applications. I deliberately stay out of the script world and am content to just work on the core software and make other people’s lives easier.

The development of the core software product is done through CVS and there are four people who have write access.  Development of script packs is handled by the users themselves, although I provide CVS access to those who need it.

As can be read in your EPIC5 1.0 announcement, it has been over 5 years in the making – what caused such a long delay before the code was labeled “production” quality?

I never really know what it means for something to be “production”, so I often butt heads with people who think that I am too deliberate about saying something is ready for production.  Those people are probably correct.  I don’t think about versions so much as package maintainer do, but I would say that
any release of epic is “production quality”, even the alpha releases, but the main issue is how people perceive version numbers.

EPIC5-1.0 was released because the authors of amnesiac (the biggest epic5 script) said that adoption of epic5 (and their script) was being held back by people who were afraid of anything that wasn’t called a “production release”, so it was decided just to wrap up all the loose ends and put something out and
call it “production”, for whatever that is supposed to mean.

How many lines of code have been written for EPIC5 and how much of the presumably old ircII codebase is still in it?

Using a very rough estimate, about 25,000 lines of old code in EPIC4 were replaced with 32,000 lines of new code in EPIC5.  The forked version of
ircII was 2.8.2, which had 44,000 lines of code.  Of that, 40,000 lines of old code have been removed and replaced with 89,000 lines of new code. Nevertheless, the lines of code that were retained are some of the most critical parts, so no matter how much old code is replaced with new code, epic will still always be an ircII client.

How much time do you spend and have spent on developing your client?

It is impossible to guess, but probably a rough ballpark figure of “at least 10,000 hours” would be about right.

What sets EPIC5 apart from other clients?

I do not like to compare EPIC to other clients, because EPIC is not a competitive project, so I will dodge the question by answering what is different from EPIC5 than EPIC4. ;-)

One of the major forces behind EPIC5 is making things simpler.  I’ve always been averse to breaking backwards compatability without a really good reason, but at some point you have to just say that something is not done the way you want it to be done and go in a new direction.

In EPIC5, many features which have been around since the very beginning of ircII were removed, and some were scripted and provided as a /load you can use for backwards compatability, and some things went away.  But these things we removed were things that made the client slow, or complicated.

One example which everyone runs into immediately:  In ircII (up through epic4) it’s always been permissible to create alias shorthands:

alias m msg

which behaves exactly the same as if you did:

alias m {msg $*}

and the client has to actually handle this internally, at runtime, with an observable performance penalty.  Plus, let’s say you don’t want the $* to auto-append:

alias e echo This is a test

and then you do:

/e booya booya

It will do:

This is a test booya booya

Then you’re left wondering, “why did it output booya booya?”  Because you don’t think about how auto-append-of-$* is always there, ready to pounce, even when you don’t want it.

So in EPIC5, auto-append-of-$* has been removed, and if you want $* to be included in your alias, you need to put it there.  This is fully backwards
compatable because

alias m {msg $*}

works in all ircII clients, going back as far as you want.

By not having the auto-append-of-$* feature to support at runtime, the internal code of epic5 is much simpler and that allowed me to optimize an observable speedup in the overhead of running an alias.

This is just one example.  Put altogether, epic5 is faster and less complicated than epic4, and that makes it much easier for me to avoid writing buggy code that leads to crashes.

Since there are other ircII forks like BitchX and ScrollZ in active use what sets EPIC5 apart from those?

IRC is a communication medium which has really clicked with IN personality types (MBTI personality sorting).  IRC won’t ever really be mainstream since
IN personality types are rare in the public, and most people who use irc will say they “don’t get it” and they move on to yahoo or aim or whatever.

Each irc user has a unique experience, and it is that experience that keeps them coming back.  Some people just want to talk to others, some people want to wage war on a massive scale, and others want to tinker around and learn stuff.  EPIC offers a “some assembly required” experience, presenting you with a giant toolbox of toys to play with and inviting you to sit down and learn about them and see what neat things you can do with them.  And it’s great fun that there are people to talk to while you’re tinkering.

For those who need an out of the box solution, epic isn’t really appropriate so they tend to gravitate towards the other clients that give them the experience that they need to make them happy.

Have there been any specific criteria that made you keep the ircII scripting language and not change it to something more “popular” like PERL, Python, TCL?

The ircII language is tightly bound up with every facet of the ircII experience.  When you start up an ircII client, you’re presented with an input line, but what you don’t understand at first is that it is an ircII command line.  When you start writing your first script, you realize that you just put in stuff that you normally type at the command line.  Then you realize that everything you might put in your script you can type at the command line.  There is a harmony and congruence to the experience.  Your script(s) and the input line are part of one large indivisible whole.

Other clients that are based on other scripting languages often have a duality about them because you don’t interact with them at the command line in the scripting language.  They have one personality when you type at the command line and another personality when you write a script.  Depending on the type of person you are, this is either great, or it’s off-putting. Each person gravitates towards the client that provides them the experience that they are looking for.

EPIC supports other programming languages by “shelling out” to them using ircII commands.  You can run ruby code doing something like:

/ruby {
<insert ruby code here>

and since /ruby is an ircII command, and all it does is runs the inside of the {} in a ruby interpreter, you can use it anywhere.  You can even use it to run ruby stuff at the command line!

How can the community around EPIC5 get involved and what kind of support are you looking for?

EPIC is like every project and needs three things all of the time:

1) Those who are willing to write scripts or script packs
2) Those who are willing to do work on the core client
3) Those who are willing to write documentation

but participation has never been mandatory to be part of the “community”,  because we’re all just friends and it’s enough just to be friendly and chat with us.  IRC is about socialization, and sometimes, that’s enough.

Will there ever be versions of EPIC5 for other operating systems such as Windows or MacOS or is that completely out of scope?

EPIC5 should compile right out of the box for cygwin (windows) and MacOS X. But what it won’t ever be is a graphical program, which is probably what you
were really asking.  You will still have to run epic in a command shell or terminal emulator, no matter what the operating system.  There are very fine graphical clients out there, and ircII isn’t trying to offer that experience.

How secure is your code? At least BitchX had (and according to Wikipedia still has) security vulnerabilities that can at least lead to a crash?

Everybody measures ‘security’ differently.  Back when I started, I wrote crap code because I didn’t know what I was doing.  But now I’ve learned what does work and doesn’t work, and it’s hard to write insecure code when you know what makes code insecure and you don’t write it that way.  I run epic under
valgrind and bounds checking gcc and use all the warning flags I can find, and I avoid all use of “unsafe” functions.  These are just patterns of success, not guarantees of invincibility.

Do you or have you used any other clients besides EPIC and if yes, why?

Since EPIC is exactly what I want in my irc experience, I don’t usually try to run other clients, because that would just remind me of how they are only
approximating what it is I already have.  I actually prefer to talk to people who use other clients, and ask them what they like about that client and what they don’t like about epic, and then go about making those changes.

Looking back at your developmental progress, are there any decisions you would take back if you could?

Well, looking strictly from hindsight, there are always decisions you make that limit your options in the future. But it is only by stepping out of my boundaries and trying to do new things in new ways that I learned how to write good code.  So mistakes are to be expected, and rather than a source of shame and frustration, they’re opportunities for personal growth.  So no, I wouldn’t want to change anything, all my mistakes have been fortuitous.

Or something that you would have perused more?

If there is anything that I have never been accused of being, it is being too hasty to make decisions. ;-)

If you could change something in the IRC protocol itself, what would that be?

I actually have always been very happy with the simplicity and elegance of the irc protocol, and I’ve always been one of those guys who wished that people would stop trying to “fix” things that aren’t broken. ;-)

But in seriousness, there have been times I wished it were easier to track responses to requests with their responses.  This would eliminate the need for the server to treat all traffic as a strict FIFO,  But this is a very minor thing.

Development aside, what do you use IRC for in your leisure time and which networks do you frequent?

I use EFnet and Undernet primarily.  The main epic channel is on EFnet and has been there continuously since 1997.  We have an emergency backup epic
channel on just in case something happens to EFnet.  I also visit wasteland on undernet, mostly because I know many people there.

There are numerous topics, polls and postings about a possible decline of IRC – what do you think about that and where do you think is IRC heading in the long term?

I think IRC will always have a place because it is an open system that is uniquely suited to certain types of people.  As long as there are two people who want to use irc (and I’ll be one of them), there will always be an irc. Whether other people don’t want to use irc any more is no biggie to me because I can’t ever expect to make friends with millions of people, but I tell you that the probabilities are a lot higher for me on irc than off irc.

What are your future plans for EPIC5?

The immediate project is to try to add support for unicode/utf8 so people can talk to others on channels where they use utf8. ircII clients have always assumed that everybody uses 8 bit code pages, which is a relic of 10 years ago. Sometimes it’s hard to break with the past.

Thank you very much for the interview – any last words to our readers?

Remember, irc is meant to be enjoyed, so just have fun and don’t lose perspective on things!

Many thanks to hop for this really insightful interview and also thanks to Zilog for the tip regarding the EPIC release!