The Good and the Bad about IRC Technology
A lot of broadcasts
Jutut's document concludes recommending to use the /away command. Actually, there is a scalability issue 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.
Then again, these are considerations worthwhile in the 90s. Nowadays IRC can hardly generate large enough traffic to cause trouble. So, go ahead and use /away.
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 of who's seeing you, and who's not. In the end, notify has essentially given way to presence in channels.
PSYC instead has a 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.
The IRC URI drafts
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:
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.
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 ;)).
IRC server variation that didn't make it
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.
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. IRC daemon developers later responded to that with advanced flood detection logic.
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
Then again, see Snowden considerations.