Those who fail to learn from IRC inevitably reinvent it, and fail. The major point of an IRC network is that a single server cannot seriously impact a network. Then there's Freeloa--er, I mean, Freenode, which takes a wonderfully decentralized system and creates a central hub and point of failure. And eggdrop, which creates a private IRClike server where everyone connects to usually one bot using the wonderfully NAT-unfriendly DCC protocol. And then there's the IM "chatroom" bots, most of which have implementations that depend on a single hosting user to be available and connected in order for anyone to use them.
IRC may have its flaws, but most of these stem from poorly thought out "enhancements" to the protocol unique to each server network designed either to add features or combat abuse. If these features had been properly vetted and given the weight of an RFC, the protocol would be today both more streamlined and less prone to abuse through individual points of failure. Things that could/should have been implemented: - Identity mechanism as protocol IRC itself simply knows the IP you're from, the name you wish to be associated with yourself, and the username you or ident claim belongs to your account. For ages, ident was considered a security feature, but these days it is a joke that servers still even care what your reported username is, let alone whether ident provided it. Additionally, most IRC servers, realizing that a spoofed IP is easy and that ident is a joke, implement a password-protected nickserv or variant. The problem with nickserv is that it is a nonstandard extension which lives on its own server (single point of failure) and may or may not be integrated into the local server as a command or require that you send your commands to [EMAIL PROTECTED] (both for added security..) These passwords are sent plaintext. Learning from the lesson would be to require an identity, probably with a valid email address associated, and use a challenge/response. This should be done as part of the login process. If you're on a server, you're "identified". Most of the IM systems do this, though some do indeed send plaintext passwords over the network. - Online/offline contact One of the extensions many IRC networks implement is a memo server--a way to send a short message to someone who isn't online. ICQ allowed this, and although AOL implemented the feature into its Oscar protocol, it was never part of AIM. Reasons cited are mostly security and confidentiality, but it probably had more to do with bandwidth and storage for something a user might just stop checking one day. More reasonable, and implemented in some of these memoserv designs, is for the messages to expire after 7 days. None store the messages in anything but plaintext to my knowledge, but that could be corrected easily enough. - Single server failure IRC doesn't get this right ever. You have a network of servers, and they may have some sort of round-robin DNS or something. Or you may have to find a list of servers and connect to individual names. When it is not crippled, as is often the case, any server can tell you all of the servers currently connected (and their tree connection topology, which is why the feature gets crippled). Part of the connection handshaking process should be to acquire a full server list from the one you connect to, so that your client knows how to contact the network, not the individual server on it. The IRC protocol does not mesh well with anything other than leaf to branch to branch to root propagation of messages. This is a design flaw, and can/should be corrected. Each message should have a hash associated with it that define the sender and the unique message. When a server sees a message, it simply passes it on to all servers, and to those clients who would receive it, provided that it has not seen that message before. The table must expire, but an emacs session takes more RAM than would be needed to store a table that expires entries that are ten minutes old. Now, IRC lag is sometimes that long, but only because of the tree topology used in routing messages today. Clients, too, could connect to multiple servers. This can be fairly transparent--currently the server admin sends a message to users telling them to move to another server. If the client has a list, it can receive a message from the server telling it to migrate away within two minutes. The client could at that time evaluate the server with the fewest hops, connect to it, and then drop the connection to the old server without missing a beat. In fact, if lag exceeds a given threshold, say ten seconds, the client (and indeed the servers as well) can re-evaluate their current connection(s) and migrate as necessary. A client might maintain two connections, while a server might have three or four. Unresolved: a server might be close, but have a narrow bandwidth allocation. Existing "smart" server selection methods don't try too hard to deal with that. - Channel "ownership" One of the most inconsistent things about IRC is the whole concept of channel ownership. Originally, by joining a new channel, you became its owner. Then you could decide who else would be owners. There was no distinction between owner and manager and many chanop wars were fought. Then came the *serv bots or equivalents and suddenly there were access controls for working with the bots, but not the channels. Either you had chanop status and could do anything (though it could be undone if the network was set up to allow that), or you had to send commands to a bot to do the things you were allowed to do for you. That's messy, just integrate the access controls. Do away with the concept of gaining operator status entirely. When you join the channel, you have whatever status you are given. No asking for that status, and no message which though worded differently translates to, "don't piss off <foo>, he's now a chanop!" Such messages just egg the kiddies on, and are a waste of bandwidth anyway. - Ban, +bquiet, silence, etc You have to understand something about IRC modes. Basically, they are letters, and they may or may not have arguments. Sending something like MODE -o+b you [EMAIL PROTECTED] is generally how a person is banned (removing operator status, in case they have it, then setting a ban on the IP mask, which prevents them from joining.) You could also do that -o you +b [EMAIL PROTECTED], and the +- thing is sticky, so you could do something like +ooo foo bar baz to give chanop status to your friends all at once. Somewhere along the line, bots began to automatically kick a person from a channel when a ban was set on them. If they can't join the channel, why would you allow them to remain? +bquiet is why, it basically makes them unable to talk to a channel, but still able to see what other people say. If they leave, they can't come back until the ban is cleared. Then there's voice, a mode that allows people to talk on a moderated channel, the moderated channel flag, the Freenode "quiet" list, client-side /ignore, server-side ignore (/silence), and a host of other haphazard methods of controlling who can talk to you or to your channels. Worse, because identities are basically your screen name, your ident info or reported user name, and your IP address, ban evasion is a pretty big deal, as is responding to a ban with ping floods and worse since you can see the IP of the person who just banned you. Some servers cloak that information, but that breaks DCC pretty rapidly. - DCC sucks! The way to do anything between two leafs on an IRC network directly is to establish a DCC connection. The problem is, a DCC SEND or DCC CHAT (initiated, not accepted) involves asking the other leaf to connect to your machine. DCC REVERSE never got widespread acceptance, the mIRC client's /dccserver command is a hack that can't be done on a multi-user system, and generally the whole method DCC is negotiated and established is not exactly firewall or NAT friendly. The server needs to arbitrate this a little, and then get out of the way once both ends have opened and connected to whatever ports they need to in order to establish a bidirectional communications channel. It wouldn't hurt if you could choose whether the connection were TCP or UDP, etc. IM extensions allow voice and video, games, whatever. (Multi-user chatrooms plus the option to go off and have private video chat with a person? Tie it in to myspace and you have the ultimate way for teenagers to willingly put themselves at risk trying to find other hopefully also teenagers to get laid... But still, technology should not legislate people's behavior.) The problem is that despite the shortcomings of IRC, as extensive as they are, the closest alternative is IM, and IM just doesn't have the features necessary to match, let alone surpass what IRC does today. On Thu, Aug 10, 2006 at 10:48:15AM -0700, larry price wrote: > Sorry, it looks like the bot died last night after I went to sleep, > I've restarted it; but don't have time to watch it during the day. > > On 8/10/06, Jeff Newton <[EMAIL PROTECTED]> wrote: > >Okay, here's the deal, I put in first eulug as a new instant message and > >jabber > >came back with a 404. Now, I put in the other [EMAIL PROTECTED] and it > >shows up > >on my buddy list as the person is not online. > > > >I am using [EMAIL PROTECTED] here on my end. > > > > > >Jeff > > > >Mr O wrote: > >> You could try going to 'Buddies', 'Send Instant Message', type > >> in euglug (possibly '[EMAIL PROTECTED]'), and in the drop down > >> box be sure to have the right account selected. > >> > >> TBA, > >> Mr O. _______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
