[IRCServices] A discussion on the contents of the todo file

[Imran Ali Rashid]

Warning: this is a LONG email.

>Things to probably do:
>CS Allow banning single host only, not hostmask, on autokick
>CS Merge appropriate channel flags with LEVELS settings

Whats the use of the first suggestion? you can do the same if you do it directly. *!*@host
I'm guessing the second suggestion is with regards to setting flags and having access levels
for it. Correct me if i'm wrong.

Here onwards I'll mention "Things to think about"

>** Anti-spam pseudoclient: kills people who send messages to it
>  (warning first?)

Whats the use of this? Firstly you would have to put the client in a channel since almost all auto messaging scripts do
it by seeing the nicks in different channels. And if you do put it in a channel, how is to be decided which one?
Assuming u allow people to do put the psuedo nick in their channel, or u do it yourself, how will you differentiate
between geniune people wanting to converse with new people and auto messengers... In this case, a warning would
definitely be a must.

> CS NOBANS channel option

I don't see the use of such an option. If you don't want anyone banned, then tell your ops not to ban anyone, and if u
can't control your ops, don't make them ops. If you follow this further, you might come up with more suggestions where
the founder can't control his ops and wants services to do it for him. Something along this line is even mentioned later
on.

> CS No target on OP/VOICE means self

Although just a convenience, it should be easy enough to implement... were there any objections on this?

> ** "Blacklist" of evil users to prevent them from getting +o/+v

Isn't this already there ala access list autodeop. set the nojoin level to -2 and use this at -1.
As far as novoice goes, it could be added the same way autodeop is there.

> ** Warn about being kicked off after N password failures

Why not put this in the help message? You could also send it after N-1 tries.
Has there been a discussion on this?

> ** Use an easily-parsable log format (eg: <time> CS REG #chan Founder)

Whats wrong with the current format?
I guess it would be better to have it in terms of the exact command used and so on, but I don't see how it will make a
big difference, unless there is a standard to follow, which there isn't as far as I know but correct me if i'm wrong.

> OS REHASH command

Please Please Please put this in.
and umm a slightly different behaviour as compared to the SIGHUP signal.
I refer to the fact that everyone has to identify again.

> CS SET REVENGE (reverses ban, etc. set by lower level user on higher,
  and optionally deops/kicks/bans lower level user)

Are you sure you even want to consider this????

> CS Last used time for access, AKICK entries

This is a good idea. This was even mentioned by someone recently.
So lets discuss it and see how many people like it.

> NS SET INFO to set an info line for INFO command (like channel descs)

sure why not. Its an added feature, but I don't see any serious objections to it.
Although it would probably be very low on the priority list.

>NS Show services oper/admin/root status in INFO

I don't see why this is necessary... If you want to let people know who is what, make it a separate command. But I don't
think that either of the suggestions(the todo one and the one i just mentioned) is a good one.

> NS SET ALL (especially PASSWORD) for all linked nicks

When I read this, I became curious... related to linking.
Some people link to nicks in a channels access list and the person never knows, all it requires is for him to know their
password just once.
Even the channel founder is sometimes baffled, since he can't find out. You have to go to a services admin.
Why not add a command to let people know which nicks are linked to theirs(after identifying of course), and add
something to chanserv to let people know how a person got opped(the linked nick being a case in point).

> MS MemoServ IGNORE {ADD,DEL,LIST}

If a person wants to irritate you and u put him on ignore, whats to stop them from getting another nick and sending
another memo? to help against this and cases of memo flooding, a command may be put in to get rid of the memos of a
certain nick.

> CS Allow hiding of INFO information a la NickServ

Sure why not.

> ** Add a way to send OperServ (and other?) commands from the shell

This is defintely a big help. but how about just having a telnet session with services, since that would facilitate an
easier access to commands, and is a seemingly good idea... I'm waiting for people to shoot holes through this, since I
haven't really thought on it a lot.

> ** Services log channel
Was there a recent discussion on this?

End of mail :-)
Imran Ali Rashid