The way you can log in to the cbstream chatterbox client has just been changed.

The new mechanism is as follows. Join both the #cbstream and #cbstream-login channels on the irc server irc.freenode.net. Then write a message to the #cbstream-login channel saying “loginyour-perlmonks-usernameyour-perlmonks-password”.
You need to be identified to freenode to be able to do this.
You should then be able to talk on the channel #cbstream and the messages will appear in the chatterbox.

Once you're logged in, you may part the #cbstream-login channel if you wish.
You may replace login to plogin in the login message to login permanently if you take care not to divulge your freenode account password.
To log out, send cbstream a private message saying logout.

That couldn't work securely. The problem with it would be that when cbstream is down, another irc user can log in with that nick, and if someone sends a message to cbstream at that time, that user would immediately get that message. What's worse, even if a user would be so careful as to check that the real cbstream bot is up before he sends a message, he couldn't do that without a bad race condition, because an impostor could watch the #cbstream channel for when the cbstream bot dies, and when it does, change the nick of another irc connection to the server to cbstream immediately.

The alternatives to the current solution are the following. The code for the previous login mechanism (using memoserv) could be improved a bit, but that seems to be a dead-end to me. A separate html form you access on http could be used to log in. Finally, I could use a channel that you can write without joining (which is very similar to what you mentioned), but because of a limitation in the irc server freenode uses, this can only be made work if I made the channel invite-only so no-one but the bot joins it, and I feel this would be a bit less convenient than the current method.

As a huge cbstream user, yes, that would be WAY easier. It's also easier to trust (even if it is less secure). I had to do a triple-take today logging in via the channel where I saw a bunch of other users sitting there - didn't want them to see my password!

In many ways, I would have preferred a web interface where I could just write a small script with WWW::Mechanize to pass my user/password across. Then whenever I find myself logged out (due to a cbstream-bot-reset), I could just switch over to a console and type "login_<tab>", see the "login_to_cbstream.pl" show up on my command line, hit enter, and be pretty much assured of as much security as anything else (seeing as perlmonks doesn't use ssl, either). Probably easy to launch from Xchat, too...

But who am I to complain ... it's still, overall, FAR easier to use (for me) than any of the other CB interfaces...

I basically have three reasons why I think logging in on irc is more convenient than on a web form.

Firstly, on a web form, you have to enter your irc nick separately, which is error prone, whereas on irc you automatically cannot log in anyone else than yourself.

Secondly, the users only have to set up one application, not two. Many irc clients have at least some scripting support, so a user could even fully automate that when he goes on irc, the client joins the cbstream channel and logs in for him. Similar is true with a very dumb irc client: I have used irc to get support from an install cd that only gave me a busybox rescue shell. I could use the wget nc command to submit a simple web form, but if you already have a connection for irc open, it's easier to just type one or two commands there than mess with a web form.

The third point is the convenience of implementing on the server side. It would be possible to write a cgi that runs in the webserver, and make it transmit the data to the cbstream server, true, but it seems much easier to make the cbstream server accept one more kind of input as it already has the irc connection open. This is especially true to the new channel-based login mechanism, which is actually even easier to implement than the memoserv-based one, only I didn't realize this back when I wrote the memoserv handler.