[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
(!) 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! :))
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! ;-)