Current state

Instant messaging, like ICQ, AIM1 or similar, is not very different from IRC. With both IM and IRC you can see, who is online, chat and maybe even start external programs using the IP-number of your "friend", if the server reveals it.

IRC has the advantage to be an established, open standard and is not bound to special servers.

The only advantage of IM that I know of is advanced access control. You have the ability to define, to which "friends" your presence is revealed. On IRC, your presence is revealed to everyone who knows your nickname or is in the same channel.

Proposed solution: IIM

Using appropriate clients, it is possible to emulate the access control features of IM with IRC.

Basically, we simply have to make sure, that noone can guess your nickname, but we reveal it to predefined "friends".

Obscuring nicknames shouldn't be that hard, we could simply use a long enough random string. If the user changed the access control settings (e.g. makes himself invisible to someone), the nickname changes, too.

Revealing the current nickname could be done via email. One special email address would identify one user.

If someone wants to add a remote user to his "friends" list, he passes the special email address to the client, which sends a defined message with his current nickname and the prefered IRC server/network to the remote user. If the remote user chooses to authorize the requester, his client sends a defined mail with his current nickname and the prefered IRC server/network back to the requester.

If one of them wants to chat, his client transparently connects to the prefered IRC server of his "friend" and querys the secret nickname (or trys to open a DCC connection).
(Note: to avoid problems with IRC networks, the client would try for the specified nickname on all currently connected servers first before opening a connection to a new one.)

If the "friend" is found to be offline, the requester could send a message (a defined mail with the message text included).

It is also possible to chat with multiple remote users, creating a channel and chat in the usual IRC way. The client could perform the secret nickname -> choosen nickname translation.
(Note: see "Open problems/Channels" below.)

Like mentioned before, if the user changes the access control settings (e.g. makes himself invisible to someone), a new nickname is generated and sent per defined mail to all still authorized "friends".

Advantages

Advantages over IRC should be clear.

In comparison to IM, this approach would have the advantage of relying on neither any proprietary or new protocols (apart from the defined mails) nor services offered by special companies.

In conclusion: Why creating new services, when the same can be achived by extending the established ones?

Requirements

Client

The client must be written to enable this service, although existing implementations can easily be modified to do this. Basically, you'd have to throw together an irc and simple email client and add some special details basically described above.

Server

No new server software must be written.

Protocol

Standard protocols are used: IRC, mail send and retrieval protocols (SMTP, local mail, POP, IMAP etc.). Mail protocol is extended to make autoprocessing of messages possible, but is fully backwards compatible.

Services

The user must be able to access both a "home" irc server/network and the irc server (network) of his "friend" (both can be the same). Additionally, he must have an email account, which can be accessed by his client, and be able to send mail to his "friends'" accounts.

An exclusive email account for this service is prefered, although it is possible to share it with normal email.

Extensions

Protocol details not yet addressed

Security

Real security (authentication, encryption) will be included in the standard as optional (if such a standard will ever exist).

Presence Information

Status, alternative access methods etc. on a per-"friend" basis.

Open problems

Network borders

The user can only see "friends" logged into the same network. This behavior is intented, but might not be wanted by some users.

It's in the responsability of the client to implement the behavior the users wants. Possible alternatives:

Channels

As soon as two users chat, they can watch each other until the next secret nickname change.

Creating a channel could reveal the nicknames, because channel names might be published.

IP addresses

IRC servers often reveal IP addresses of logged-in users and make a IP-address -> nickname mapping possible.

Scalability

User list

Description

Data about logged-in users is populated across the network. This might be a serious problem with huge amounts of IIM users and without optimization of servers. (AIM currently has < 2 million logged-in users at peak hours.) Quote from RFC1459:
9. Current problems

   There are a number of recognized problems with this protocol, all  of
   which  hope to be solved sometime in the near future during its
   rewrite.  Currently, work is underway to find working solutions to
   these problems.

9.1 Scalability

   It is widely recognized that this protocol does not scale
   sufficiently well when used in a large arena.  The main problem comes
   from the requirement that all servers know about all other servers
   and users and that information regarding them be updated as soon as
   it changes.  It is also desirable to keep the number of servers low
   so that the path length between any two points is kept minimal and
   the spanning tree as strongly branched as possible.

Proposed Solution

A possible solution could be that servers "subscribe" on other servers, too, instead of collecting all data.

Scenario: client A connected to server A, client B connected to server B. Client B wants to keep track of presence of client A, so client B asks server B, if client A is online. Because of that, server B asks server A to be informed about the presence status of client A. From now on, server A "pushes" all status updates about client A to server B. Client B requests this information the same way current IRC clients do (see "Notify pull").

Done this way, the IRC client/server protocol stays the same, but the (IRC) server/server protocol has to be changed to represent the new strategy.

Notify pull

Notify lists are currently implemented on the client side. The client does a /whois or similar for every "friend" (entry on the notify list) every x seconds (called POLLER).

This is only a local problem, because the local server can handle the requests on its own.

Nicknames (advantage)

Since IRC nicknames are generated (space: approx. 250*10^12) and IIM nicknames (the ones presented to the user) don't have to be unique, nickname problems are properly addressed (similar to ICQ, in contrast to IRC or AIM). Quote from RFC1459:
9.2.1 Nicknames

   The idea of the nickname on IRC is very convenient for users to use
   when talking to each other outside of a channel, but there is only a
   finite nickname space and being what they are, its not uncommon for
   several people to want to use the same nick.  If a nickname is chosen
   by two people using this protocol, either one will not succeed or
   both will removed by use of KILL (4.6.1).

Security

See "Extensions/Security".

Nicknames are only obscured, so it is possible that somebody gets knowledge about the identity of an IRC nickname (and with it the presence of its user) without the awareness of its user.

IETF

The following requirements of the IETF IMPP Draft might not be met (apart from the above):
5.1.1. The protocols MUST allow a PRESENCE SERVICE to be available
independent of whether an INSTANT MESSAGE SERVICE is available, and
vice-versa.

7.2.1. The protocol MUST include mechanisms so that a sender can be
informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons
for failure.  The working group MUST determine what mechanisms apply
when final delivery status is unknown, such as when a message is
relayed to non-IMPP systems.

8.1.3. The protocol MUST provide B with means of allowing an
unauthenticated subscription by A.

Links

RFC1459
IRC protocol
IETF Internet Draft: Instant Messaging and Presence Protocol (impp)
Design goals for IM, no protocol yet.