Wonderful World of Irssi2

http://iki.fi/tss/irssi2-intro.txt

  ** Wonderful World of Irssi2 **

(for building up hype before anything works :)

  * What is it?

Irssi2 is a client/server architecture based protocol, where the clients
mostly just take care of placing the messages into screen, while the 
server
takes care of all the difficult things. This makes it easy to develop 
many
different clients for different needs without having to reimplement all 
the
features.

The protocol is based on events. Events can be sent to clients 
realtime, or
old events may be requested again later. Events can also be filtered 
with
different conditions, so bandwidth isn't wasted for events the client 
doesn't
care about.

Events are mostly generated by gateways. Most common gateway would be 
your
normal client connection to IRC server. Other gateways could be ICQ, 
AIM,
MSN, Jabber, SILC, etc. Nothing requires events to be about chatting, so
you could create gateways which notify of new emails, errors in log 
files,
or whatever realtime notifications you are interested about.

  * That sounds great, but what does it actually mean to me?

It means that you can keep multiple clients open simultaneously. For 
example
you can keep the same session open at home and at work. Or you can use 
"you
have new messages" applet much like "you have new mail" applet.

All clients (including newly started ones!) have access to the whole
scrollback. You can do searches based on whatever criteria you want. It
would even be possible to keep event logs stored in disk, allowing you 
to
have easy access to everything you've ever seen in IRC!

All in all, this means there is no need for IRCing in screen anymore. 
You
can have all the advantages of graphical IRC clients without any of 
their
disadvantages.

  * So, will there be irssi2 client?

I haven't really decided yet. I'm much more interested about writing the
server myself, so hopefully other people will the clients. Perhaps the 
old
irssi code could be modified somewhat easily to support the irssi2
protocol, but I don't see much point as I'd prefer to run GUI client 
rather
than terminal based given the choice.

  * What great new features does the irssi2 server have?

It handles many of the things that were previously handled by IRC 
clients:

  - Notify lists
  - DCCs (either to server or directly to client)
  - Highlighting, ignoring
  - Scripts (user interface scripts would still be in clients of course)
  - Logging

New features include:

  - Searching and retrieving old events
  - Updating old events. For example update changes in highlights or 
ignores
    to old events as well.
  - Full text search indexes to make it possible for clients to show 
search
    results as the search condition is being typed.
  - Connecting to gateways (ie. IRC servers) is much smarter than before.
    It has full support for round robin DNS addresses (try every IP), 
and if
    gateway doesn't reply immediately it starts connecting to next one 
while
    as well. Whichever server finishes first is then used.
  - Separated user and presence concepts, see below.
  - Provides centralized location for storing client configuration. This 
allows
    you to have identical configuration whereever you start the client.
  - Character set conversions. Clients use only UTF-8.
  - Server administrator can give users default configuration for things 
like
    networks, gateways and commonly used character sets in them. This 
makes it
    easy for users to get into IRC without knowing any of that.
  - Servers can connect to other servers and show the remote server's 
data as
    if it was it's own. This makes it possible to "extend" remote 
server's
    features by placing a local server in front of it with the features. 
And
    most importantly, because of this clients do not need to (I would 
even say
    MUST NOT) support connecting to more than one server.

  * Users and presences

User is a single real world person who can have multiple presences. With
old irssi you had to create a new network for each of your presences 
with
duplicated server settings. Now it's possible to create multiple 
presences
with a single network configuration.

Users are created manually and configured to find one or more of 
presences
of the user. This could be done with nickmasks (eg. 
nick!user@*.host.org)
or some other means (eg. nick=foo*, channel=#foo, realname=Foo Bar).

Talking to users (instead of presences) can have several advantages:

  - If presence changes a nick, or reconnects using another one, the 
messages
    are automatically sent to correct nick
  - If one presence gets lost but other presences could be reached, the
    messages can automatically be routed to working ones. This is 
especially
    useful during netsplits when both users are in multiple networks.
  - If presence's commonly used nick name is used by another user, 
irssi2 can
    issue a warning and ask if you really wish to send the message to 
this
    unknown presence.
  - If user uses multiple clients (eg. home and work), irssi2 can
    automatically check which presence has the least idle time and send 
the
    messages to that one.

  * More about events

I have very high hopes of what will be possible to accomplish with good
event filtering and searching. It makes it possible to have a really 
simple
to use client showing only the very essentials, ie. private messages and
channel events. But if something actually goes wrong, there would be a
button to allow digging into all the old events to see what exactly
happened.

Don't you just hate seeing the constant server reconnection messages,
especially when network is really broken and it keeps reconnecting and
constantly flooding your screen with useless information? In my dream 
GUI
client you wouldn't see any of the reconnection messages by default. 
There
would be a simple colored flag in statusbar. Red flag=not connected, 
yellow
flag=connected to some servers, green flag=connected to all servers. If 
you
click the flag, it shows status of each server with details of why it 
isn't
connected.

  * Future...

Users often don't really care about what goes on in the server side, as
long as they can keep using their favorite clients and talk to the 
people
they want to.

Now, assuming irssi2 will take off very well and soon nearly everyone 
are
using it as a server, it means that simply by upgrading the server 
support
can be added to new server<->server protocols. Irssi2 servers could 
start
talking directly together, or to special channel servers which host 
only a
couple of channels. After this, the need for IRC networks drops. Or 
rather
there would be many small "networks" which host only a couple of 
channels.

The advantages of this are many. Because there wouldn't be large 
networks,
denial of service attacks would practically disappear. DoSing a network
down would kill only the few channels that it was hosting. It also means
you could immediately talk to any irssi2 user just by knowing their
user@host address, very much like with email. No need to go hunting down
for servers that let you in to some IRC network. And, of course, it 
solves
all the scalability problems with IRC.

  * What about Jabber?

Irssi2 is still mostly about being an IRC client, although it gets some
Jabber-like features. I still haven't looked at Jabber much, but from 
what
I've heard it's mostly about IM and wouldn't work too well as a 
replacement
for IRC client for accessing IRC.

Could irssi2 be implemented on top of Jabber protocol as extensions?
Possibly, but I don't think it's necessarily very useful or even a good
idea. I like human readable and writable protocols, and XML isn't that.
It's not even easily machine parseable (libraries only hide the 
problem).
XML also feels way too complex for this task.

  * Status

I have somewhat working irssi2 server which allows multiple clients to
connect to it and allows connecting to multiple gateways, joining to
channels and sending messages. Not much more and even that isn't 
perfect.

What I would mostly need help with is designing the irssi2 protocol 
itself.
Especially the filtering. What would be the best way to specify what 
events
you are interested about receiving?

Also client implementors would be very much appreciated.

  * The Code

http://iki.fi/tss/irssi2-0.1.tar.gz

Currently it starts in foreground and creates a client connected to your
terminal. It also starts listening for new clients in
~/.irssi/client-listener. irssi2 will most likely be integrated into
Dovecot to provide SSL and user authentication.

Here are also some example commands you can feed to it, source code 
tells
you the rest:

http://iki.fi/tss/irssi2.txt