Research in synchronous conferencing systems

These are the folks doing research:

• PSYC is the Protocol for SYnchronous Conferencing. It provides a generic messaging framework plus a scalable IRC replacement and a new level of abstraction concerning conference control. It has a notion of "plug-in" multicast strategies, so you can apply different routing technologies to it. IRC client-compatibility is available, so you can check it out rightaway by issueing /server psyced.org. legacy compatibility for jabber is also available. you could say, this is a solution that actually works.

• Gerrit Hiddink has implemented a plug-in replacement for the IRC server using a new server-to-server protocol (better multicasting, less overhead, TCP however) called WWCN. It still uses the model of interconnected servers like IRC, although they can be freely interlinked now. It has seen a successful deployment at HIP'97. You may want to look into that.

• Timo Sirainen of irssi fame has thought of an IRC+ thing which looked very PSYC-like. Then moved on to do something completely different called Icecap.

• ircd - The IRC developer list has tried to become an IETF working group and develop a proposal for a new protocol. A few proposals did get written, but soon the process froze.

• Undernet's Coder Committee made some neat extensions to the IRC protocol, but didn't however solve the major problems IRC is facing today yet, either. May '97: They have started a new mailing list very similar to the "big" IRC developer list.

• Adam Ierymenko is working on an IRC plug-in replacement, too. It's called Nexis Chat Protocol (NCP). This one too uses an approach based on interconnected servers, although using UDP. I'm afraid it replaces multicasting with broadcasting though. Not sure. The website has disappeared. Huh?

• Yet another IETF working group wanna-be: ircup - The IRC Update Working Group. but they started working anyway. So far the basics have been pinned down. Lisa Dusseault from Microsoft is in this group promoting the MSN extensions to IRC.

Other chat protocols

• Reliable Multicast protocols on top of IP Multicast. They do not scale for large amounts of channels, though.

• The MMUSIC working group at IETF in charge of the MBONE are working out protocols for reliable multicasting over Multicast IP as well as dealing with scaling issues when it comes to having thousands of small conferences. These issues have proved hard to solve though, so a lot of work needs to be done by the involved researchers. We're all eagerly awaiting their results. KUTGW! (Keep Up The Good Work)

• Project-Y was a conferencing/collaboration extension to Mosaic, probably comparable to NCSA's own Habanero efforts, but Mika was looking at ways to redo IRC starting from there. Nowadays hardly anyone knows, Mosaic was the original web browser. Project Y has disappeared.

• The InterMUD protocols are still in use for intercommunication between Multi-User Domain Servers. Both Intermud2 and Intermud3 are still in use. Number two is unreliable (UDP) and insecure, but peer-to-peer, whereas number three uses a central node which runs proprietary software. Most MUDs aren't exactly happy with both solutions. Güldenland has adapted psyced to serve as an Intermud4 protocol. Nice and effective.

Instant messaging protocols

• jabber is an open-source instant messaging protocol which passes around XML packets. a quite ugly syntax which combines the verboseness of textual protocols with non-line-orientedness (thus losing out on the advantages of not using a binary protocol). As an IM protocol it seems to operate well and is being extended all the while, but as with other IM approaches no proper multicasting is considered to resolve the conferencing and presence "friendcasting" aspects, therefore it cannot be considered an IRC replacement. In fact it is already running into scalability problems. The IETF has made jabber a standard called XMPP, neglecting the inherent scalability issues.

• Can't find a homepage for the Rendez-Vous Protocol (RVP). It was brought up by young enthusiasts at Microsoft Network. It is a decentralized Buddy List Protocol, and that's it. Chat programmers think buddy lists are a problem that is solved easily once you implement a chat properly, just add some presence message types. Buddy list programmers instead think chats can't do the job, and neglect multicasting. Go ahead and decide for yourself. :°)

• The ICQ protocol, as unveiled by hackers. Implementing anything according to this is probably the fast way to make yourself totally dependent from a particular company.