[ahf]

It's not true that this is up to the clients authors alone to do this work, and it's not fair for the users to tell them that you are awaiting client adoption of various technology, when the current Quakenet ircd implementation is currently incapable of even accepting SSL connections. Or at least it was, last time I checked.

Also, the DANE support in Irssi was announced in September last year and I have only heard of one network where some of its servers have adopted to this technology. Even though there is only one client that currently supports DANE+DNSSEC verification, we still need the (big) networks to start preparing for the support of it, and help us reaching the point where we can secure our user connections even better :-)

Having SSL on IRC, even without DANE+DNSSEC, is still better than having no SSL at all.

[pferde]

This is why I am disappointed that SILC[1] never got off the ground in the mainstream. It could have been an elegant successor to IRC.

1. http://silcnet.org

[welterde]

I blame the reference (server) implementation leaving so much to be desired. Primarily stability.

I tried running a silc server alongside my ircd for a while, but it never even reached a weeks worth of uptime without crashing (no matter if debian package, self compiled stable or devel, or some minor messing with the source).

Perhaps if a non-C/C++ implementation comes along..

[pferde]

No, it wasn't that. There used to be (maybe still is, I didn't check) a core group of reliable servers. I remember having a client idling on them for weeks without reconnections.

What was missing, I think, was lack of client development and adoption. There was default CLI client which was a weird fork of Irssi, then there was plugin for Irssi, and not much else.

There were of course few small client projects, but few of them got past early alpha stage.