IRC


If you are searching for information on IRC in general, please visit irc.pages.de. If you need help on how to access PSYC with an IRC client, check the Help. If you want to have a gateway into an IRC network, that is described in Gateway.

Contents

The Good and the Bad about IRC

The problems related to IRC technology are very well described in RFC 1324 (A Discussion on Computer Network Conferencing). You can read on in Functionality and Problems of Systems for Synchronous Conferencing. See also the PSYC whitepaper and several other documents in the tech area of the PSYC site. In essence, IRC has scalability, security and addressability problems related to the volatileness of user and channel data. Notice also the one big good thing about IRC, it has a notion of multicasting. See also Centralistic for a comparison of IRC with other chat technologies.

No more IRC-style netsplits on PSYC

... at least not like this.. http://www.bash.org/?124895

It's different with PSYC: If an Internet link breaks it will affect those people who are on that link, but it will not tear down a whole network. The difference is, IRC sends the traffic through certain servers, causing itself bottlenecks of higher traffic were PSYC creates multicast networks for each context, thus the load is spread more evenly across the involved nodes.

While on IRC, the hub network servers are fine targets for bored attackers, who mean to harm just one context of people (place, channel, chatroom, whatever you want to call it), but actually affect the entire network, on PSYC bored attackers can still attack a server concerning a certain context, but that won't impress the rest of the PSYC network.

That didn't make sense, yet? Okay let's go into details. IRC shares a large database of user and channel data among all servers of a network. When a link breaks, all data from that route becomes invalid and needs to be retransmitted when reconnecting the server, causing load to the entire network. In PSYC, this kind of data is static - when a server disappears, communications to that server are disturbed, but all other communications are fine. Also, there is no need for large syncing, once the server is restored. XMPP has the same kind of approach here, with the same advantages over IRC, but it also does not multicast, therefore running into other scalability problems described on the Jabber page, where IRC performs better. PSYC takes the good aspects of both. See the netsplit page for more words on the same subject.

IRC is oligarchic, not federated

In the foreword to the book IRC hacks, Jarkko Oikarinen, inventor of IRC, writes:

"It was and still is the possibility to network individual chat programs (IRC servers) to one another, thus forming a worldwide, distributed, and decentralized chat network. The ability to network, without maintaining a central location of control, has been the key for success for IRC, WWW, USENET News, and many other systems."

It may technically be correct to say IRC is decentralized, but politically it is not. To maintain order on the network, to protect conference control in chatrooms (channels) and in modern IRC networks, to protect user identity, every single IRC server needs to trust every other IRC server on the same network, completely. This implies that an IRC network must be implemented by an organization of people who trust each other not to abuse their administrative rights to exercise random and unaccountable executive powers on the network. This shortcoming is one of the reasons why the single all-encompassing IRC network for the world could not be achieved. The other is the technical scalability problem of IRC, making it impossible even for an organization like the United Nations to be in charge of such an endeavour. NNTP, the protocol at the fundament of USENet, has the same political prerequisite, causing it to turn into a wild west forum in the 90s, then leading to the irrelevance it has today. Unfortunately, IRC is at a similar level of irrelevance when compared to the huge centralistic IM systems. So the only true success story in the listing above is the WWW, which is indeed decentralized, both technically and politically.

PSYC does not enable vanity operators, unless you make a special change (a tuning) on your server to implement them.  :)

The IRC Syntax

Since IRC uses a function-call like syntax, parameters have no names, they only have an order. You can always only add things at the end of the list to extend the syntax. Various protocol dialects even do this in differing ways. PSYC has solved this elegantly with the psyctext and variables syntax! We could have used XML, but... there are plenty of reasons not to do that.  :°)

Identity on IRC

Jutut's document on how to idle on IRC explains how changing your nickname is bad, because you are changing your identity and can no longer be reached. This is a basic problem with IRC that can be partially addressed with NickServ, but to be sure you are seen by the people that should see you, you have to stick to your nickname.

PSYC only allows for nickname changes within chatrooms with enabled masquerade. Ironically, IRC clients cannot see these changes, as they would become unable to send you private messages if we forwarded them such nickname changes. IRC has no notion of purely cosmetic nicknames.

A lot of broadcasts

Jutut's document concludes recommending to use the /away command. Actually, there is a scalability problem with that. A lot of operations on IRC like entering channels, changing modes, going away, are broadcast to the entire IRC network. Technically this still is a multicast, but it affects every single server on the network. Such operations are considered expensive and as a result IRC admins always try to keep the number of servers to a minimum and the number of users on each at a maximum. Quite a tricky balance. Unless, of course, you are running a small network, then you can only talk to not so many people. So, on large IRC networks, there is no really good way to go away. ircII comes with an auto script which simply informs people about you being away as they try to talk to you. This is the only solution that does not cause any harm.

Bye bye notify, enter presence

It was around 1989 that BigCheese implemented a way to find out who's online by checking the IRC WHOIS command periodically. It was one of the dirtiest hacks ever written, but it worked. People loved it. Later /notify's impact on useless bandwidth consumption was slightly reduced by the introduction of ISON polling rather than WHOIS. Server-based solutions were also created, like AWAIT, NOTE SPY and service-based presence mechanisms.

Many of these had privacy issues, as you could monitor any nickname of choice - so changing your nickname became necessary to have some kind of privacy, which in turn meant that best friends needed to poll also your private nicknames etc. ad infinitum. Hiding from some people made you unavailable also for others, and you weren't always in control who's seeing you, and who's not. In the end, notify has essentially given way to presence in channels.

PSYC instead has a server-side presence mechanism similar to Jabber's. It works by subscribing to somebody else who will at her will let you know when she is available. So if you use an IRC client, please keep it from doing any notify operations and use presence instead. It is a lot lot lot more efficient and accurate. PSYC also has a notify command itself, but it does something else and is not necessary generally.

Concerning the IRC server implementation in psyced

See the Help pages for help on how to use IRC with PSYC.

The IRC URI drafts

There are 3 non-optimal drafts for irc: URIs out there in the wild. We looked at them and took what's best of each. See on IRC URIs.

Uniforms as nicknames

As the IRC (RFC 2813, Section 3.3.1) states that a valid nickname may not contain the '@' character, some IRC clients may not be able to parse nicks of the form ' xmpp:user@host '. We don't know of any intolerant IRC client in fact. Using uniforms is no problem with any of the major clients. Should you however manage to encounter one, you'd have to issue a

 +set verbatimuniform off

This will encode uniforms in a strictly compliant way, which however raises the degree of confusion in your PSYC experience:

 xmpp:user%host

Regardless of this setting you can send messages to both uniform styles.

We have recently started injecting such uniforms into entire IRC networks using our new IRCgate, and still haven't heard of any client that runs into problems handling them.

Okay, there is a historic one: irssi 0.8.9 is the only known client which does a nickname parsing, which is not advantageous for psyced. If you have that version running, you can do the +set verbatimuniform off trick. Even better if you simply upgrade your irssi as the new version now parses nicknames in a PSYC-friendly way. Thank you.

No matter which client you use, you may want to define server-side aliases, so that remote users (PSYC, Jabber™ or other) appear using local nicknames. This makes your PSYC-ircing experience smoother and more familiar. Look up the psyced manual for details on that. In fact this should be automatic, in order for psyced to behave more like an IRC server. See the alias page on that.

Passwords - no nickserv

If you want to connect automatically, you can set a server password for your identification. In irssi this would mean: /connect <server> 6667 <password>

There's no need for nickserv-scripts or anything else like this.

You can however use /nickserv or even /msg nickserv if that makes you happy. We added an emulation of that.

CTCP PRESENCE

Also have a look at PSYC Presence as we have introduced a new CTCP PRESENCE protocol! Fifteen years after CTCP ACTION.. ;)

Evil client automations

Do you see the message You need to enter something first? .. Maybe you are running a Miranda and you need to turn off "Update online statuses for users" in the Account tab. Or maybe it is something else in your respective client (please add it here when you find out ;)).

Bots

When porting IRC bot technology to PSYC, avoid logging it in as a fake person. It's nicer to have these applications integrated as services or programmed places. See the bot document.

Historic Documents

History of Bitnet and IRC in a 1992 retrospective, unfortunately held in german (See also BITNET). The articles are taken from Terra's Chalisti, an organ of the CCC of the late 80s. Except for Terra the CCC was generally not very interested in the Internet in those days. Pattex was more exciting. cute posting from 1989. Ausserdem: Wettrüsten im IRC auf Sociology.

IRC server variation that didn't make it

1991 announcement for an enhanced IRC server ...

The new features are:
-       AWAIT [<nickname> [<nickname>..]] stores a wait-for-user request.
        Server then informs you of signon of a user. You can also
        await a server, you will be informed as soon as it links up
        to the network, but you may not use *'s because masks are not
        allowed with AWAIT.
-       REFUSE [<user@host-mask> [<mask>..]] does a 'server-ignore'.
-       A gateway protocol is included, used by the BITNET->IRC gateway.
-       VOICE, GRPH and XTRA are not converted to PRIVMSG anymore.
-       LIST displays also the channel modes.
-       All replies are numeric. The output is in SMTP/NNTP/FTP style.
        No more NOTICE's coming from the server.
-       Auto Unlink: The server automatically connects to the net when the
        first local user signs on and unlinks if noone is using the server.

Server-side notify and ignore would have been a great step forward. And XTRA would have been a nicer way to do CTCP rather than use the 0x01 code. And oh, looks like I invented numeric replies in IRC. Also auto-unlink was a smart measure to reduce network traffic. Too bad that I had some stupid crasher in the AWAIT code, resulting in Jarkko not bringing my changes into the official ircd distribution. A reason to hate C: memory alloc stuff.

NickServ taken down after Jupiter killed it

An important episode in the history of IRC was when the very first NickServ was killed by an operator who then renamed himself into NickServ and made fun of everyone who sent him passwords. Just recently (2006) the same incident happened again on freenode.

The thread shows how the 1991 public wanted NickServ back and wasn't at all happy with the policy of nicknames not being owned. The thread also mentions the IRC War that had taken place before and led to the separation of the EFnet from the free IRC later also termed Anarchy-Net by the EFnet people.

Historic operator discussion after NickServ was shutdown: http://my.pages.de/pub/net/irc/logs/nickserv_wallops.gz

This also leads to the next discussion on getting rid of nicknames in the protocol:

WiZ wanted user@host-Notation

This interesting thread on owning nicknames mentions that WiZ (= Jarkko Oikarinen, originally writer of IRC) wanted to upgrade IRC identifications from nicknames to user@host syntax. Wumpus added, that clients would have to manage the nickspace for the user then and even I had a hard time imagining an IRC without nicknames at the time. Troy went on to extend the protocol to provide for nickname suggestions to clients. Too bad nobody ever coded this. Wumpus went on wisely recognizing that the /names command would turn out unusable in future IRC considering its growth rate. Finally Alan D suggests an /expand command which essentially does what our /alias command does, only on server side.

/wallops was a bad idea

The WALLOPS (write to all operators) command was introduced for ircers to quickly be able to cry for help. It became an exclusive operator-only chat channel with a lot of envy from non-operators who wanted to take part in the discussions. It also had the inverse effect of operators prefering not to wear operatorship just to avoid receiving those messages. On one legendary occasion in January 1991 a wild wallops discussion led to a completely absurd KILL war of operators where everyone was shooting everyone else. The log of it is a quite amusing read: http://my.pages.de/pub/net/irc/logs/killfeast.gz Also the kill paths give you an insight into the topology of the IRC network back then.

The Battle Of Eris - The War Of IRC

At the beginning there was only one IRC network: The IRC.

Several people in the original IRC network thought IRC should remain open, that everyone who wants to chat should, if desired, be able to do that under his own administration, with his own IRC server - they essentially subscribed to the principle of federation and thought IRC should fix its protocol to support that rather than stop free minds to run their own IRC servers.

Unfortunately some people only wanted to run servers for vanity reasons, acquiring operator powers on the IRC by connecting to an open server, then showing off. Nothing really serious, IRC was a terrifically peaceful place in those days. However, IRC had a technological problem there, and social and political repercussions followed.

eris.Berkeley.EDU is the machine that became symbolic of this tragic development, as its administration firmly decided to leave open C/N lines for anyone to connect an IRC server anywhere in the world. In fact there had been several open servers in the early days (like irc.belwue.de), eris was just the last one to fall.

After lengthy discussions on the 'open server issue' on operlist, the mailing list for IRC operators, a group of administrators decided to eject open servers from the IRC network. The new 'Q' line (quarantine) was thus implemented into ircd, specifically with the purpose of rejecting eris.

But what really triggered the war was the publication of killer.c. The inventor of the IRC himself, Jarkko Oikarinen, wrote up a bunch of lines of code to display how easy it would be, to break apart an IRC network with open servers.

Everybody knew how easy it would be, but nobody ever wanted to disrupt IRC like that, not even the vanity operators or any other supposedly evil hacker. Introducing the Q-lines was a preemptive strike against IRC terrorism that didn't exist. IRC could have waited until things would have gotten that bad before taking drastic measures.

Now that this code was published, one IRC administrator took it, fixed it, and executed it. What followed was the biggest disruption in IRC service the IRC had seen until that day. Soon the newly invented Q lines were activated by a small group of administrators.

For several weeks the IRC network was to a large extent unreliable as the Q-enhanced servers would disconnect any server who dared to introduce eris into the network and administrators who felt abused by this political decision tried to connect eris back into the network. They felt like a piece of Internet freedom was breaking away.

In fact the Q-line was peripheral in the war. The real battleground was the huge majority of servers who didn't care whether they were on an open or closed IRC network. The few administrators with a political opinion, either on the open or closed side, would repeatedly disconnect them from the opposing network and connect them to theirs. In other words, the war was fought by a bunch of operators using /squit and /connect commands.

Eventually the freedom defenders gave up, eris was ejected and the newly created oligarchic IRC network was given a new name: Eris-Free Network or EFnet.

Some of the administrators decided not to go along and stayed with the original IRC network. Since that didn't suit the EFnet policies to admit the original IRC network to be the original IRC network, they also rewrote history and named it ANet as in Anarchy-Net. The actual administrators of the original IRC never chose that name themselves, but they admittedly adopted it for the sake of distinguishing the two sides.

With brute force the majority of people however were taken to EFnet. The new political policies of it soon led to new IRC networks, Undernet and DALnet, as many weren't willing to accept somebody else's oligarchic rule.

Technologically, open IRC networks aren't manageable - so IRC had to adapt - either by rewriting the software, which was the path I took with PSYC, or by splitting into several closed networks, which was the way IRC took.

I suppose the path to EFnet could have been a peaceful one of democratic agreement, and probably with the first serious abuse of the so-called open-server servers it would have happened, instead the change came unnecessarily soon and without a warning.

Read IRC History as seen by Vegard to see the same history as seen through the eyes of an EFnet administrator.

Sir Wumpus and the return of Eris

After the war, the Q-lines especially invented for eris.Berkeley.EDU stayed up and occasionally an operator would try to connect it back.. http://my.pages.de/pub/net/irc/logs/sir-wumpus.wallops-chat.gz

Wow, that brings back memories! -- Sir Wumpus

How SPAM began on IRC

It was around 1991 that BigCheese decided to implement event hooks in ircII, mostly for the purpose of restyling the output of messages, so if you didn't like how NAMREPLY was displayed on your screen, you would define some "/on names * echo $xx this or that." Unfortunately, some people quickly figured out they could set-up something like "/on who * msg $1 SPAM message", then do a "/who *". Yes, that's what it took for unsolicited messaging to take off on IRC.

Antitestimonials

On alt.irc, Doug McLaren says:

    Yes, IRC overall is losing `chat' marketshare, both
in terms of percentages and in terms of actual numbers (as the market
is growing.)  But to really die out completely will take a very long
time.

But the reasons you've given are *totally* wrong.  IRC has several
problems --

   -- no central control, each server is run at the whim of it's
      operators.
   -- difficult to scale well
   -- unreliable -- the standard protocol doesn't allow redundant
      links, for example.
   -- difficult to set up/install for the end user.
   -- channel control issues and abuse run users off
      (ops, bans, kills etc. tend to get in the way as often
      as they help)
   -- lack of pretty pictures, avatars, etc.
   -- a reputation for only being used by `bad' people
   -- IRC is generally run by amateurs/volunteers, and it shows.
   -- and there's lots more.

Now, various issues have been resolved to various degrees by various
networks in various ways, but ultimately IRC is `old skool' now.

Probably the biggest factor is the ease of use.  If you want to talk
to Grandma on the Internet on her new computer, do you have her
download AIM and use that (and it just works), or do you have her
download mIRC, then pick a network, then a server (is her ISP
k-lined?), and a nick (let's hope it's not in use or already
registered) ...
In the same thread, Chika says
As I see it, the biggest problem with IRC is the increasing tendency for users to set up their own servers rather than use what is already there, the increase leading to an increasing isolation of potential users.

<lynX> Users are no longer willing to accept the oligarchic political structures of IRC, and especially to deal with the behaviour you can expect on large IRC networks, so they start their own, to serve their own requirements. Unfortunately IRC cannot federate, so they can only communicate with the peers that will join their little networks. An obvious situation where PSYC can help. Have your own server, but still talk with everybody.

<coyo> which, btw, is pure unadultered awesome

Documents

Retrieved from "http://about.psyc.eu/IRC"