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
