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.
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".
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?
An exclusive email account for this service is prefered, although it is possible to share it with normal email.
It's in the responsability of the client to implement the behavior the users wants. Possible alternatives:
Creating a channel could reveal the nicknames, because channel names might be published.
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.
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.
This is only a local problem, because the local server can handle the requests on its own.
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).
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.
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.
1 AIM is a trademark of AOL. The concept of human-human communication is patented by AOL. >