RE: [NeoStats-Devel] Secureserv and non-VERSION ctcp requests

Justin Hammond wrote:
> Agreed that its not cool how they do it, but I think DNB 
> raised a interesting idea, in that it would be good if we 
> could extend the CTCP API to process "unknown" CTCP message 
> types in the future without having to go and release new versions.
[snip similar]

My post said that this was a known limitation of the CTCP system that was
known and would be addressed and I even provided the names that would likely
be used for the API. I would have done it already but I am reluctant to make
any changes whatsoever to the CTCP system until the issue that you
experience with core version checks is fixed and the "argument" over the API
resolved.

I do not understand why you are saying this system would be good to have
then describing a system I already said would be added? Am I missing
something you are adding?

> This way, should a new trojan/bot come out (there are already 
> a few out there now) that warrant a new type of CTCP check, 
> we can easily implement it via the Dat file (with some 
> modifications of course to the Dat file, which will have to 
> happen with the planned perl support regardless)

I have been asking for changes to the dat file for years, literally, but
they are not yet available so it seems odd that this could be added adhoc
while my requests which you appear to have agreed to remain in limbo.

> Well, like you state below, just a generic catchall CTCP 
> interface should be what we look for, then we can easily 
> extend SecureServ with a new dat file rather than a new release. 

The particular suggestion made was for support for a specific issue so a
jumpthroughmyhoops module would be better placed than creating DAT file
entries for SecureServ in this instance since it would only catch a very
small subset and only be useful to a small subset of networks using
SecureServ. Any anti bottler or similar specific module could jump through
all the necessary hoops without having any additional work done on
SecureServ. I see no point in adding bloat to SecureServ that does not have
tangible benefits for SecureServ as a whole.

If there is some benefit in SecureServ performing unknown CTCP request/reply
check based on the dat file, then this needs additional work within
SecureServ in the first instance since SecureServ and the dat file assume
CTCP means VERSION. In its current form, SecureServ could not even process
the known standard request/reply sequences let alone a mutable format.

Assuming you are going to make changes to the DAT file format, then I think
we need to nail down a new format pretty quickly and future proof it so that
we can change it in the future without affecting existing installations
rather than the current inability to make changes since it might affect
someone running an early and no longer supported alpha.

Mark.