It would be nice to have native SCHAT support (Secure/encrypted DCC chat).

Currently I'm using a script to be able to initiate SSL connections to for example Eggdrop 1.8 IRC bots via "/sockopen -e" but there's no "/socklisten -e" so this thing currently works one-way only. Another reason the scripted solution sucks is because it has no support for highlights, unlike the true native mIRC DCC chat, and also spaces are not preserved in the text.

I know there's ways to fix the spaces problem (for example using spaces.dll), and also ways to have highlights (probably via simple if-then-else statements).

But if going that route, this then becomes unnecessarily bloated that it would just be best to have native SCHAT support in mIRC itself, the core (encryption) is already implemented so I think this should be doable with not too much effort.

There's an SSEND too, but I'll keep the request to SCHAT.

Some documentation: http://www.kvirc.net/doc/doc_dcc_connection.html

The issue here isn't implementation but rather the lack of a standard for SSL DCC*. This has resulted in various clients implementing SSL DCC's using their own vision for how the public certificates should be traded and authenticated. If mIRC was to support SSL DCC it'd have to support each of these differing implementations or we'd end up with various requests and bug reports about how mIRC isn't able to successfully maintain a connection to a different client. To complicate matters even further, most implementations do not make it known *WHICH* implementation the client intends to use. CTCP versions cannot be trusted and the DCC messages do not contain unique fingerprints to identify the implementation used.

*: The link you posted doesn't even specify how a key exchange should function:


How does a user, wishing to host the DCC chat specify its certificate, signing authority, etc?
How should it work if the hosting user does not have a registered certificate?
Should self-signed certs be allowed, and if so, how are they to be negotiated?

These are questions that (1) need to be answered and (2) standardized otherwise mIRC will just be adding yet another SSL DCC implementation to an already crowded field.

mIRC can use the Windows certificate store if I'm not mistaken. mIRC also has configuration options to specify a private key file, a certificate chain file and a trusted authorities file. This also works with self-signed certificates for which you will get a prompt to either accept or reject the connection, just as it does now when connecting to IRC servers over SSL, and even as "/sockopen -e" does.

I think it is safe to require a certificate be set when the mIRC user itself is the hosting party and return an error when attempting to do so without one set. I think this should work with KVIrc, Eggdrop and possibly other clients that already implement SCHAT.

I was hoping to see more support for this request and not have it become another impasse by simply doing nothing instead...

Edit: I'm curious though, since you say "already crowded field", how many *native* (thus no scripted) SSL DCC implementations do you know about? I only know of one, maybe 2 (if they even differ). Eggdrop's and KVIrc's.

I don't really want to bump old threads, but it has been 8 months and 3 releases without any word from the one person that can actually implement this in mIRC.

Given that many of the necessary plumbing is already in place, can we please get native DCC SCHAT support?