Hi

Hi.

Hi. Its me again. I've gotten a few queries and a few mails from you guys since I wrote last time so I wanted to answer some of the questions that you asked the most. Due to the nature of your questions this will probably be somewhat technical (read: boring).

All those damn services.

_The "L" Bot - our new lightweight channel service

_Lets start out with my baby, L. L has been in betatest a little more than a week now, and it is working really well. The webrequest system is functional and integrated into the new webpage which should go live soon. There are still some undecided things about L though:

• L can either be in the channels it is registered in, or it can operate the channels from outside. The reason for it being in the channels is to make it more familiar to you guys, just like Q. If L sits on the channel all the time, the topic will also be preserved. The main reason for not letting it stay in the channels is that we expect a lot of empty channels (due to the loose requirements, more on those later), and by not having L in those channels they will not be created in the ircd and will therefore not take up RAM. The burstsize will also be preserved this way.
• The requirements to get L have not been decided yet. All channels will be able to get L if it's up to me. There has been some talk in the oper group that we should require 4 people to be opped in the channel, but I think that this will only be an annoyance to you guys and have no practical effect on L. I am concerned that L might be used to takeover a channel though. To prevent this I lean towards a scheme that is as follows: EITHER the requestor must be amongst the top five ops on the channel as recorded by chanfix OR the requestor must have been a known op in the channel for at least 48 hours. Together with this the requestor must have ops in the channel at request time (which prevents old clanmembers from requesting L). For new channels this means that the channel must be older than 30 minutes before you can request L. I think you guys should be able to wait that amount of time.
• Expiration times for channels and accounts. Just like in Q, channels and accounts will have expiration times in L. Currently I've thought about something along the lines of: Accounts expire after 35 days unused (40 in Q). Channels expire after 20 days unused (no authed people known in the channel have joined it) (again this is currently 40 days in Q). Together with this I plan on removing channels from L if no user has flags in them. Please note that this makes people with +n on a channel able to remove L from a channel; care should be taken when +n is given to other people. Normal channels should probably only have one or two people with +n.

There are also some notes on the L manual. A couple of you guys have offered to translate the manual. This is very kind of you, but I think we should wait until the manual is in its final form. Quas is currently working on integrating it into The Guide. When that is finished translations can be done, but not before as things will probably change. Oh, and 'tahan' means 'here' in finnish, so the urls are www.url.here.com as Strutsi didn't know where they should point yet.

_The "S" Bot - our spam protection service

_I've gotten a few questions about S too. There are mainly two things you guys are in doubt of:

_Why doesn't S autojoin?

_S does not autojoin as we want to give the respective channelowners a chance to have a say about their own channels. Making S join all channels with more than 100 users is quite easy, but we feel that channelowners should be able to decide themselves what level of strictness they want on the channel, ranging from none to strict.

_Why not let the ops on the channels handle it themselves with kick/ban?

_It is quite clear that channels with 300+ users cannot be handled with conventional tools, such as kick/ban. Users will rejoin very fast or try and evade the ban. It is my opinion that users simply get too much value compared to what the conventional punishment is, and a lot of users can unfortunately not handle that temptation. We decided to raise the bar a little by first in the test period raising the punishment to a network kill, and now that S is running in full production mode, we have implemented g-lines (network bans). G-lines are not issued before a network kill has been issued though, so people have fair warning.

_Instagib.

_S had an 'instagib' setting which would kill offenders on first offence. Needless to say that this was a bit too excessive. It was meant only as a test setting, but snuck into a few production channels. We apologize for that. The setting has been removed from S and people should get a warning in most cases before they are thrown off for breaking our network rules.

_Ircd (irc-server software)

_Functionality has been written to filter colours from quit-messages. The purpose is to be able to make channels completely colourless, as most of you guys clients shows quits, parts and joins in the channel windows themselves. It is also being discussed whether the filtering functionality should be put into the +c channelmode. My opinion is that we should preserve cpu cycles for now, until we switch to Undernets 2.10.11 version, which will, from what we've seen so far, kick ass and chew bubblegum at the same time due to new neat network code.

_Release of the services.

_It should be quite clear that my opinion is that we should release all the services we program. This is not our first priority however: The prime objective is to give all you guys a good service; making others able to use the stuff we develop comes after that. Things like the ircd are pretty much ready to use, but not ready to release as the documentation for it hasn't been written yet. Some of you may say that we should just release the stuff without documentation then, but this has been tried and coders have been forced to change nicks and part public channels due to people wanting support (and it was even clearly stated that no support would be given to those released services). So in my opinion we should not release stuff without documentation for that reason. We have had positive experiences with releasing services, with quite a few bugs has being found in L due to you guys being nosy. Thanks for helping there.

I've thought a little about a FAQ about how to start your own irc-network too, we might put such a thing up together with the services when they (hopefully) are made public.

Helpers.

_Structure.

_The existing helper structure is built up around a help board that decides rules and guidelines for the helpers. The board consists of a couple of helpers and a couple of opers, where the helpers on the board have been elected by the other helpers. Helpers communicate through the #help channel, through their website (http://help.quakenet.org) and through a private mailinglist. The help organisation was made an official part of QuakeNet at one point because there were a lot of people who wanted to help out with supporting the users, but we didn't dare to make them all opers. This was mainly due to the existing oper structure not being able to cope with many more opers, but also because it is hard to trust strangers that you do not know in real life (I feel more secure in having an oper I know I can hit the next day at work if he fucks up).

_Benefits.

_Helpers have some small benefits compared to the normal users. Call it salary, perks, whatever. I think they deserve a little something when they dedicate time to make the support level higher. Helpers have their own dedicated server, which has a number of fake hosts that they can switch to (support personnel on irc-networks have been known to be targeted directly from time to time), and they can be on a higher number of channels.

_Powers.

_Helpers have up until now not had any special administrative priviledges to help users. This is wrong in my opinion, because if I cannot do anymore than you, I cannot help you anymore than you can help yourself. Support is not possible without extra priviledges. This, I believe, is also one of the reasons that it has been suggested that helpers get priviledges to examine things about the network. They will not get priviledges that have to do with the internal connectivity of the network, nor will they be able to throw people off the network, but they'll probably be able to tell you how long your friend has been g-lined, or tell you for how long a channel has been unused.

*Bots.
*Eggdrops and the like are and always have been very welcome on QuakeNet. Due to the new opping service, ChanFix, I recommend that eggdrops are given an account in Q and that they authenticate when they log on the network. This will make it easier for us to know who has a legitimate right to a channel and who has not. Mulitple eggdrops can even share the same account, and that way take over if a bot goes down and needs to be backed up by another bot from the same bot-network. Bot owners should not have their bots ask O for ops constantly though. We will not tolerate this. Please make your bots smart and don't do things that will put our services under heavy load (this may not be a problem with a single eggdrop, but if a couple of thousand eggdrop starts to poll for ops in channels where they allready have ops, it may be noticeable to performance). I will see if I can get somebody to build an eggdrop script to enable easy configuration and communication between eggdrops and L. Eggdrops are very welcome to supplement L in channels - this will probably be a good combination where people want a little more functionality than L can provide, and a little more security than an eggdrop can provide.

*This and that.
*Hmm, what did I think of but not write above? Probably something about openness: Although I advocate for openness, I think the operators and helpers privacy should be respected. Unless explicitly stated, please do only interact with operators/helpers that you know. Due to some users stalking operators and helpers in channels, we've decided to hide the information about what channels we are on, and what channels we have flags on. Getting a couple of queries each minute simply isn't fun when all you want to do is discuss tic-tac-toe tactics with your clan.

That's about it.

Rasmus aka. 'Bigfoot'

PS. I am not a native english speaker as some of you may have noticed. This is largely hidden by the fact that Tom 'cro' Gordon corrects my articles though. Thanks Tom :-)