[this document is from 1993 approximately, but is still true in many points. of course file sharing and IM technologies have come closer to the goal in the meantime, but still not close enough!] REQUIREMENTS (marked with a ?) & SOLUTION SUGGESTIONS (marked with a !) *** end-user simplicity (?) Nowadays we need a system that's easier than a phone: click on a channel name in WWW and a chat window pops up. The protocol must be an infrastructure permitting the biggest variety of trivial solutions. (!) URLs! Replace the builtin directory services with the URL concept. This I think is a fundamental issue which simplyfies things greatly. Once a person and a channel has not just a one-time identifier, but a long-term URI, thousands of ways open up for people to get in touch without the need of having them related with the protocol. How does it work: A person's or a channel's URI is a pointer to a server which simply holds information about this person. The server doesn't relay for the person, it just tells where the person currently is. Truly simple, yet no protocol does it like that. *** what to do with the global database? (?) IRC spends most of the time updating its database. How can we free ourselves from this? URLs? (!) Yes URLs!! Once we have URLs we can put them in our homepages, signatures, web-based databases, even in books! Noone will miss the /who command. (?) I can't imagine finding people without the /who command. (!) Well you can still have /who for the people around you and the people on your favourite servers, but an internet-wide /who is crazy anyway, and that's what IRC has always been trying to do. no, it's better to search for an interesting person's web pages, emails or news postings and then add their URL to your contact list. +++ suitable for business: secure & stable (?) No more hackable channels and stuff. (!) No centralistic structures that make anything depend on anything else. Let the "clients" communicate directly, keep routing on lower layers that cannot interfere. Then again, if it's better to have your server route everything in your channel, you can configure it that way, too. It's a per-channel design choice. +++ open for future developments/protocols (?) Today we have the worries of TCP, UDP or Multicast IP. Tomorrow we could be running on incredible new protocols. (!) Why provide *one* multicasting subprotocol if we can sort-of define an API on how to handle several types of transport mechanisms? Say network object URI is accessable by the following set of protocols (mcast:URL, udp:URL, isdn:URL). Total flexibility. +++ open for multimedia (?) We can't make a protocol that can't gif or video! (!) That doesn't mean we have to implement real-time protocols. Others are doing that for us. We just need to provide the one true conferencing control that glues all protocols together and gives a person a true network identity independently from the protocols he can currently handle. But additionally to that, we can provide a default subprotocol which supports content-types - so you can start chatting in text/html or text/x-moo instead of just having IRCs text/x-ctcp. +++ centralized ergo programmable channels (?) Everyone wants to have his own fancy extensions and features to a channel, therefore everyone wants to run a bot. A bot is bad. Why? Because the IRC protocol can't deal with it. A bot shouldn't consume *any* resources except for when it's being used. (!) Seen from the URI approach, the server answering at the URI can be a "bot", or a system of "bot" programs. Since every time someone wants to join a channel he depends on the server to tell him who the people are (including hosts and protocols) the server can implement all the channel access politics he wants. The subprotocols should ensure the ability to centralize channel control (although chat is multicast of course). No more channels out of synch!! Just imagine: You could hack up a channel program which does democratic voting in the channel before letting someone in - and you won't need to upgrade >100 servers on the planet!! +++ answering machines (?) Of course we still want /notify (!) But this time we do it better. This time the server that responds to a persons URI can hold pending "NOTIFY_ME" requests from friends till the person logs on. No more polling!! Additional freedom: You can have all the personalized commands and away messages you desire (and remember: they could be audio files!). +++ seperate infosystem from transfer protocols (?) To make it clear: We need to distinguish the pursuit of contacting a person or joining a channel from the actual communication. They are two totally different things worth having different protocols! (!) When I say server I'm really talking about something a bit more intelligent than an httpd, but not actively internetworked with other servers. The new situation demands that whatever there will be to multicast the communication, it shouldn't be the same thing which does the politics of it (channel control etc.). POINTS OF CRITIQUE: You might think it's risky to depend on one machine to have a network identity. Yeah well.. (a) on the web we're doing it all of the time (b) I can still think of "multiple channel authorities" if implemented properly - not the irc way - and similar things for persons. Another thing is, this may sound like putting a lot of intelligence into the client. I think it *can* be that way if it's *useful* that way.. but most of the time I like to think we can have "user-agent servers" which do the hard networking job (handling multiple protocols, talking to many servers, etc.) while letting user interfaces just do the display-part of the job. In the end it could optionally emulate an IRC server so we get a smooth transition by letting plain IRC clients in, too. ==» 2003 remark: psyced is available and does just that! :)) http://www.psyced.org THE DREAM: There should be no need for any other conference control protocol in the internet. Once it's clear how you find out things about people you can implement thousands of ways to actually get conversation going -- makes things extremely easier to coders! They just code the multicast layer with a lot less worries. THE FUNNY THING: I believe a chat system using direct client-to-client links would already be a step forward out of the IRC swamp. But of course I won't mind a good multicast infrastructure! ;-)