[Eug-lug] recreating IRC with gmail chat

[larry price]

wow that was way more than I personally wanted to know about IRC,
perhaps you should write an O'Reilly book on the topic?

The Euglug Chatterbot works, in that it allows connections and accepts
commands, it's basically an IM reflector, not nearly as complex as IRC
and now that It's been properly Daemonised it'll probably on for
extended periods.



On 8/10/06, T. Joseph Carter <knghtbrd at bluecherry.net> wrote:
> 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 nickserv!user at host (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 *!*@xxx.yyy.zzz.* 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 *!*@xxx.yyy.zzz.*, 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 <newton at efn.org> 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 euglug at gmail.com and it
> > >shows up
> > >on my buddy list as the person is not online.
> > >
> > >I am using saanpregion at gmail.com here on my end.
> > >
> > >
> > >Jeff
> > >
> > >Mr O wrote:
> > >> You could try going to 'Buddies', 'Send Instant Message', type
> > >> in euglug (possibly 'euglug at gmail.com'), and in the drop down
> > >> box be sure to have the right account selected.
> > >>
> > >> TBA,
> > >> Mr O.
> _______________________________________________
> EUGLUG mailing list
> euglug at euglug.org
> http://www.euglug.org/mailman/listinfo/euglug
>