[IRCServices] A discussion on the contents of the todo file (LONG)

[Andrew Church]

>>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

     This is with respect to autokicks added by nick instead of mask, where
Services generates the mask automatically.

>I'm guessing the second suggestion is with regards to setting flags and having access levels
>for it. Correct me if i'm wrong.

     No, it's more along the lines of "make SET RESTRICTED change the
NOJOIN access level instead of setting a flag".  The current implementation
is somewhat hacked together in this respect, and I want to clean it up.

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

     I should point out that many of the things listed here I myself don't
entirely agree with, but listed anyway to consider later and hopefully
generate comments (like these).

>>** 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. [...] In this case, a warning would definitely be a must.

     It wouldn't have to be in a channel; I think the person who suggested
it was implying it would just sit around -i with a random nick.

     At any rate, if I do implement this, it will be as a module you can
load or not at your choice.

>> 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 [...]

     This is a good point.  Yusuf, what was your reasoning for this?
Is there anything that can be accomplished with this that couldn't be
done by (for example) CLEAR BANS?

>> 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?

     It's easy enough to do, I just haven't gotten around to it yet. (:
Since you can already op/voice yourself by giving your nick, this is
pretty low on my priority list, but if there's a call for implementing it
soon I'll look into it.

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

     You're misunderstanding this.  This is not on a per-channel basis,
but something that applies to a user or users on the entire network, no
matter what channel they are in.  In particular, I was thinking that
hostmasks could be used here to deal with people (or bots) who don't
register their nicks and get other people to op/voice them.

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

     The second is already what I'm thinking of doing, but the first is
a good idea as well, thanks.

>> ** Use an easily-parsable log format (eg: <time> CS REG #chan Founder)
>
>Whats wrong with the current format?

     It's not as easy to parse programmatically as it could be.  For
example, some people have suggested something like:

03/02/2001:12:34:56 N R NickName user at somehost.net email at add.ress

where "N" is NickServ, "R" is "register", and the remaining parameters
are nickname, user at host mask, and E-mail address given (these would of
course change with the specific event in question).  A format like this
could be parsed more easily by programs, though it would of course have
the disadvantage of not being easily readable by humans.

     One thing I'm considering is to (optionally, of course) keep two
logfiles: one the same as now, and one with the new format containing
only registrations/identifies/drops and similar events.

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

     If/when I do implement a rehash feature, this is what SIGHUP will
do (instead of restart).

>> 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????

     As I said before, these items are things I don't necessarily agree
with but thought merited further consideration.  But as others have also
pointed out that it's not really useful, I'll drop it from the list.

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

     I'm already planning to implement this in 5.0 unless there's some
objection.

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

     Again, this is slated to go into 5.0.

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

     I don't see why it's a _bad_ suggestion, though with the newer
servers which support +a (Services admin) mode it's not as necessary
anymore.  My aim with this is to let people know who they can go to
when they have problems with Services--though of course that's really
a network policy matter more than anything, I suppose.

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

     This is another reason to tell people to choose good passwords;
I won't rehash the arguments made in the previous thread, but if your
users are stupid, nothing Services can do can help them.

>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).

     The former is already present, though only usable by Services
admins (NickServ LISTLINKS).  The latter has been requested by other
people as well, and I'll look into implementing it for version 5.0.

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

     Since you can already delete ranges of memos with a single
command, I don't see the benefit of this.  As for the usefulness of
IGNORE, as someone else also pointed out, ignoring user at host masks
will prevent the register-a-new-nick problem.

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

     Although I haven't decided on exactly how, I hope to implement
something like this for version 5.0.  Obviously, there are security
concerns associated with allowing remote access, which I'll have to
consider as well.

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

     Not recent, but a long time ago there was some discussion about
this.  As I recall, it essentially came down to the benefit of being
able to monitor the log online (remotely) vs. the security problems of
having Services status information broadcast on the network and the
additional network load.  I personally think it would be better off
not being added, but I'm open to comments.

  --Andrew Church
    achurch at achurch.org | New address - please note.
    http://achurch.org/ | メールアドレスが変わりました。