A new CONFERENCE protocol called Cafe.

[Ralf 'Snake' Gebhart]

From: Carlo von Loesch <infn...@siemens.informatik.tu-muenchen.de>
Subject: <Lynx> A new conference protocol.
Keywords: CAFE PROTOCOL

I passed some time thinking about the ideas proposed in this newslist &
decided to try & concretize a few things, first of all I'm talking about a
NEW protocol, nothing that would be compatible to IRC, let's say that an
IRC interface would be possible, so that the new system could be connected
to IRC, but it couldn't go through IRC.

1. CONNECTIONS: The system has 3 levels of communication:

Server-server-communication:
binary, basically like this: <source-id><target-id><text>

Server-client-communication:
also binary, similar to the one before.

Server-user-communication:
ascii, direct user interface, output to screen, input with cmdchars / etc.

You may ask what the difference is between client & user, & why I want
it. The "user" is somebody issueing a line mode telnet to a server, & the
server should be able to understand basic commands such as /j for join etc.
so that people, who are banned on some weird system, do not get excluded
from the rest of the chatting world, even though they have access to Internet.
It doesn't take much, so why shouldn't people be enabled to chat via
Telnet, because some telnet always exists, when a system is connected to
Internet, instead, writing new client software for each system isn't always
as easy as one would want it to be.
The server should therefore be able to recognize abbreviations and...
I'll talk about this again later on.
The client instead is the program-controlled connection to the server,
which should be able to open windows and some other things.

2. CONFERENCE OBJECTS:
Conference objects are: User, Server, Group (was: channel)

a) the identificator.
Currently IRC uses <nickname> <servername> & <channelnumber> to identify
each of the conference objects, in my concept they all get to have a
kind of conference-id, for names cause troubles (servers connecting and
finding people having names of groups or servers or other weird situations)
The <id> can be structured like this:

<net-id> <obj-id> <4-byte-address> = 6 bytes.

The <net-id> is a number from 1 to 64 identifying the net, where we could
define 1-16 to be internet-kind nets (we only have one now, but who knows
what future will bring) and 17-64 to be other nets, the difference is
relevant for the <address>, the <address> is made up by 4 bytes - and guess,
yes, it's the internet address, while on other nets we have to interface
the node-id's into 4 bytes (for example bitnet) so only for internet
addresses the 4 bytes have a significance also for the user, and should
therefore be displayed in decimal+dot form if the user requests info about
a server, while with the others this information should be suppressed.
The <net-id> = 0 has a special meaning. In fact the <net-id> takes 6 bits,
leaving 10 bits to the <object-id>, each server gives each of his "creations"
(be it a user connecting, a group being created (group is the replacement
for channel), etc..(?)) a number, so that each server can have a maximum
of 1024 own objects. The 0-object is the server itself.

Ah yes, I don't want to exclude other nets from conferences, the whole
thing is conceived in a way it can be realized on bitnet, internet &
i-don't-know-what-other nets, and all connected together, that means also
that future brings much more users and conference data than IRC has to
couple with today, but that's what a new protocol must be able to
afford if it wants to be worth replacing our beloved IRC.

Here's the structures for the main conference objects, partly based on
what has already been said by other thinkers :-)

b) the server structure
SERVER: <id> <father=host> <nickname> <status> <name>
The <id> is the <net-id><0><net-address>, <father> is the <id> of the
Server it connected to. This data is passed through the whole network.
Knowing the <father> of each server only one "unlink" message is needed
so that each server can locally "quit" all the servers & users that
depended on that link. <nickname> is a short form of the name a user
can easily refer to, like "tolsun", "mit", "tumuc", "unido", "peru".
The <status> I propose could be like this:

< ALIVE | SUSPENDED >
is information that is spread for each server in the network.
< ACTIVE | PASSIVE | STANDBY >
is information only the directly connected servers need to have,
so it is put into the connection structures.

Active means the server is connected, alive & has active objects, like
users or password groups (see below). Passive is a server without
objects, which therefore doesn't need to have the current conference
structure updated, it's as if it wasn't connected, yet to the users
and other servers there is no difference. Standby is almost the same,
the server just decided (maybe after a timeout) to release the
connection until some user signs on, on the other hand, if someone in
the net requests a summon or so, than the "father-server" will try to
open the connection again. But, if the connection fails or any other
drops, than a "suspended" info is sent through the net, which doesn't
mean the server has "left", it just tells other servers that they can,
if they have that server in their connect-list, try to linkup instead!
Should two connections be created, than somehow one will be dropped
due to "already existing server". If after the burp-timeout still no
connection could be created, the server is declared dead, and removed
with all his sub-servers and users. It would probably be nice to tell
all users, who are chatting with people on a burping line, that the
connection is temp. suspended... if it doesn't happen too often!
While the connection is suspended all messages to it are stored into
buffers, so when a new connection has been established they can travel
the new way to destination.
A server, that links to others together, but has no own users, might
move into standby status, with the result that the servers create a
direct connection between each other.
Raise your hand if I'm getting too fantastic. ;-D
Ah yes, i was forgetting the <name>, the name now is the network address
users can connect to, for the numeric one contained in the id is of
no use to BITNET users etc., organization name & geographical location
(like "You can't find it in the atlas"). I'm not sure if this kind of
information really has to be spread and stored into every server after
all, if someone really wants to know the organization or exact location,
he could send some command to the server (let his local server do it if
he's a telnet-user or let the client do it if he's running one, so that
user doesn't need to worry, that's transparency! :-)).

c) the user structure
USER: <id> ( <host> ) <standard-nick> <status> <name & address>
where <host> is unnecessary for the <id> with the <obj-id> set to null
IS the <host-id>, this <id> is unique as long as the server is unique
(server-id's on other networks should be defined by some higher instance).
<standard-nick> is again a kind of user identification, it is the one
users use to send a private message to somebody, a user might want to
change his nickname inside a group, for some reasons of conversation, but
still be reachable for others with his official <standard-nick>.
[Some servers could even offer a netwide service to protect nicknames to
be used by other people by assigning passwords to them. If a client using
a protected nickname doesn't provide the password or change to a different
one, he gets kicked out by this special server after a timeout.]
In normal use more than one user could have the same nickname without
causing inconsistency, it would just make problems to the person who wants
to send a message to that person, he'd get a sort of weird question like
this: "Well, do you want larry from oink.cs.tum.de or from cunyvm.bit?"
It's like a tty-select on UNIX, I don't think we should /kill users for
their nicknames, if we don't need to anymore.

The <status> is the most complex element, and surely subject to change:
Here's my proposal: <status> is devided in groups: <level> <flags>
where <flags> is <VISIBLE|INVISIBLE> & <HUMAN|AUTOMATON> and
<level> is currently 0-4:
4 -- Netwide operator, these people have to be registered, otherwise
they get blasted, even if their server announces them as such.
they have technical privileges that are yet to be defined,
However nothing like reading other peoples chat, or similar!
3 -- Local operator, also someone who is entitled to enter the
operator group (a kind of channel where people having problems
can send a message to or operators can discuss technical stuff).
This operator type has a few netwide entitlements, too.
2 -- "Master" user, a user who is entitled to open up groups as many
as he likes and all the normal user stuff. This is the default a
new user gets if the server isn't setup in an other way.
1 -- Simple user, if people play around with groups, by opening many of
them or in some other way behaving badly, this is something to scare
them off with, a simple user can only open one new group, for all
of his session! And he is not entitled to send a message to a group
he's not in, so he can't annoy people in "semi-private" groups.
0 -- Guest. This is the situation where a user can only join other
peoples' channels and can request only restricted services from
servers and... well, let's not be too cruel...

The most important privileges the net-op has is to change all data in every
server. That means that he can change any data in the object structures
net-wide, I know this is dangerous, the net-op can raise or lower other
users in their level, make password groups open to all and so on.
Maybe it isn't that good after all, if he can do THIS much!
This is something to discuss & flame about again...

A little note about visibility: if a user is not interested in being
publicly accessable, he's not just marked as such, his data isn't even
transmitted to servers who do not need to know! Only those where other
people chat in same groups with them are put into knowledge, and, if
the software has not been modified by hackers, also the servers on the way
ignore the user-data, if it's not meant to be public, and just pass it to
destination, in fact no server has to care about the contents of a message
if it's just for one defined destination, so future command expansion
is no problem.

c) the group structure
Well, this should be the replacement for channel, it's more generic, as
others have said. Each user can be part of <n> groups, some by default
like "all" or "oper" or "local" (the group of local users), and some
created and then chosen, like "fin42", the future finnish group :-),
here's a possible definition for it:
GROUP: <id> <owner> <name> <limit> <status> <list-of-users> <topic>
<id> is the usual id defined by the server who created it for a user.
<owner> are 2 bytes that mean the following:
if it's null, than the group is of type public, anyone can enter it.
if it is a number between 1 and 1024, than this is the number of the
owner, he is the "moderator" of the group, he can decide explicitily
who is entitled to enter a group, in fact the users he summons are
directly put into the group, but with a flag of "standby", not really
inside. Only a message carrying the owners' <id> will be entitled
to modify the group data on all servers, and a server should check
if the message comes from the right "direction", if it doesn't it
should immediately warn all operators, cause this would only happen
if someone modified the server sources to permit that!
If the owner is negative, than the group is owned by the server itself,
this means the server handles the people who want to get it, normally
by requesting a password, if someone sends a requested-join message
containing the password this user is joined into the group. Of course
server could also make up other criteria, like a group for finnish
only :-)). If no owner is defined, the structures can only be modified
by entitled operators (in that case the server would give some info
into the oper group about the fact, so that again people misusing the
id of netwide opers could be found) except for the join stuff, if its
public, then joining is ok.
If a netburp occurs, the group is still in domain of the owner, only
that the owner isn't active anymore, the people can still chat in that
group, but nobody can be invited, new groups have to be created if that
case is found, but, in most cases no owner will be needed anyway.
<name> a nickname for a channel, can be numeric, so that good old IRC can be
interfaced into this. :-), the name should not be changed after creation.
<limit> maximum user in group number, null is endless, operators can change
this value if the group is not owned (anymore).
<status> is made out of flags, where on/off means visible/invisible.
nickname on/off, nameslist on/off, topic on/off, secret off/on.
- name off means the name of the group is not listed, neither for those
outside nor those inside, so a public channel can have a hidden name
even though everything else is visible, yet the name is needed to enter
such a channel, of course an owned one doesn't need to hide the name.
- list off means the people inside the group are not listed, this group
would then not appear in /names, even if everything else is open.
- topic on/off is obvious, a group can decide to keep it's topics hidden,
in that case the group would not appear in /list.
- secret now is somehow the combination of all, but it means more:
a secret group is not told to servers, who do not need to know it, and
to those, who are inside or enabled to come inside, all data appears
when they call /names or suchlike, let's say, with /groups they can
see the bits that have been set, and giggle if they have secret ones
at their disposition.
I decided, that if a group is not secret, at least the number of people
using it can be decovered, like /list does on IRC, because it doesn't
say much anyway, just that people can find out if others are having a
ball without letting it know. ;)
<list-of-users> The format could be: <id><f><nick>#<id><f>#...#<id>#...##
where <id> is the user-id of one user, f is a flag saying if this guy
is really active, listening to what is said, or if he's just entitled
to come in anytime (e.g. if he closed the window with the gadget).
<nick> is the nickname, given only if it isn't the official one. Also
<f> can be left out, if both <nick> & <f> are the defaults.
The right default for <f> i don't know, experience will tell if people
like to have many accessable groups or they really enter them all.
Ah yes, the <f> flag is only needed for non-public groups!!
End the # is the delimiter, could be a <spc> for instance.
End-of-List could be defined by a double-delimeter, or by putting the
whole list into brackets {...} ..., then comes the
<topic> ascii string.

d) future object structures - user defined structures!?
even future object structures could be introduced later on, like, for
example, an adventure room structure, containing the id's of other
adjacent rooms and other info, those servers who will not know such a
structure will simply pass it on.

3. PROTOCOL:
a) From server to server...
There are three formats of a message:
1) Messages with specific destination:
- a user or server
- a group of users
(a group of servers??, users & servers?,
servers running game services?)
2) Broadcast messages (for all servers and/or users).
3) The ping/pong message.

1) MSG TO; the format is: <from><to><nu><text>0
where from & to are id's, to doesn't even have to be known precisely
if it's a secret user or group the message gets to destination just the
same, because only the <address> is checked, not the <obj-id>, well, to
be exact, the server first checks if <to> is a known group, if it is, then
there must be some users/clients who want to know about this message
after it has been passed to the next servers! If the address is oneself,
then it must be some message or notice for a single user or a locally
defined group (would be found on the check before), or, if it's 0, a
server service request. These services are not bound to be the same,
they can grow with time, for example small files could be available for
the user to dump, or a note could be dropped for a user that is not
present, the server could then check the /etc/passwd if this guy really
exists. Imagining a server to run a game, or to join groups is possible,
who knows, future might find applications where this prooves useful.
<text> is the actual command and parameters in binary format! Only the
receivers need to understand the meaning of it. <nu> is a not used byte
left for future expansion, I thought about the possibility to use it as
a message counter, so that a message can be identified, the consequence
is clear: circular networks could be based on that, if servers for example
keep a history of incoming messages, they would recognize double ones &
avoid processing them. The sender too should keep a history of 256
messages he sent, so that it becomes impossible, that a message isn't
considered if it is sent again, the same way, exactly 255 messages later.
The server would detect this and choose a different message-id-number.
I have no idea sincerely, is this a realistic view? These are the kind
of things one should learn in university before thinking about them.
Right? Well - I consider it future expansion anyway, so don't worry if
it's stupid.

2) MSG ALL; here the format is: <from>0<nu><text>0
Now you know why the network-id cannot be 0, cause 0 is the way to
identify null id's! This message has somehow no destination, it means
that all servers shall process it the way the command in <text>
requires, servers won't panic on unknown commands, let's leave everything
open for expansions. What I forgot to say before: <text> can obviously
not contain the 0-char for I imagined 0 to be the EOL-marker.
(I'm just phylosophing, I don't really know if an 0 can be used such
way in the TCP/IP!). A "WALL" could be coded like this:
<network><obj-id><hostaddress>00<PRIVMSG-code><real-text>0

3) PING; format: 0
A lonesome 0, where nobody expects it, is the ping message, it is answered
with another 0. The server that pings sets the PING-SENT status in the
connection-structure, so, when such a 0 comes back, it knows it's not a
ping, but a pong! If by chance both send pings at the same time,
everythings fine, they'll interpret them as pongs on the other side.
Of course this is not for time measuring, but for connection checking
it is cool, isn't it?

Here's to the actual commands, I'll just propose some, I don't think
I should get that deep into stuff, that in the end gets decided during
development...
There should be two basic kinds of message, the message and the notice.
The difference lays in the fact that the notice appears without header,
and it can (should) only be sent by servers... and maybe... entitled
automatons? Well, that's something the local server has to cope with, then.
Then there are the conference system commands, that can only be sent to
servers or "all", like SERVER, USER & GROUP, the CANCEL command
that can "destroy" any of these structures, the REMOVE command that can be
sent by servers or opers, just like /kill. Of course correct restrictions
have to be found - only the netwide-ops should be able to kill a server,
and if this happens it should be logged here & there... or everywhere?
the MODIFY can be imagined as a multipurpose command, it's args are an
<id> of some object, the parameter number and the new value. For lists
a JOIN & PART is needed, that is a bit like a cut & paste. Of course
such commands need to be ultra-controlled!! Only the owner can modify
the registers of his group, and some registers are NOT to be modified,
like the name of a server!! On the other hand, a user is now entitled
to modify his signup name... but not his real address (userid @ node).
Of course these commands should have binary counterparts, don't get
confused by the names, they're just #defines in a headerfile. :-)
Getting inspired by the never used VOICE, XTRA & GRPH commands of IRC
I'd say that a file and/or picture dump could be defined, and that a
file dump must first be announced to the counterpart, which then
allows or not (some pic receive flag?), if a server on the way thinks
he cannot afford a dump because of too much traffic he'll just send a
notice about that...

b) From server to client.
To be exact there are two types of clients, the passive & the active ones.
News to you? I'll explain: The IRC-clients are passive clients in my
distinction, cause active clients are those, who keep their own lists of
users in the system and therefore avoid bothering the server with
/names, this has good & bad sides, but in my experience with these kind
of clients I think they should be considered.
So this part is dedicated to the active clients, for the passive ones
could either easily make use of the TELNET-USER interface or a binary one
where data is transmitted in the same format as for the server, only that
the right data arrives and the right data is permitted to leave. So the
passive client just enhances the output & this & that...
Let's instead imagine an active client in a Xwindows or similar environment.
Of course the new software would have to open windows for each group, or
mark gadgets in a way that they show they can be opened. Let's say
one window contains groups, each group with a graphic symbol that the
mouse can click on, an owned group with a closed door or a doorbell,
clicking on this symbol will cause a join-request to be sent... once..,
if the person got invited the door stands open, clicking on it will open
a window for the actual group chat. Password groups are shown with a
keyhole, selecting it the user will be prompted (requester) for the
password, or the password will be read from a rc-file. If the password's
right, then the key fitting into the keyhole appears, if it isn't then
the group vanishes. No-name groups would have a question mark, and so on.
If the client is an active one, it would get updates concerning groups
being created or canceled and show them immediately at the screen. If
the user wants to open up a group, he can choose this command from a menu
and will be prompted for the parameters in a requester-window, parms are
the name, flags, own-flag, optional password, preset topic and most of all
** people! **, if it's a public channel people just get an invite-notice
on their main window. There can be also an other window, the people window,
all people, or only known ones appear with gadgets, if one clicks on them
a dialogue-window is opened... One could dream hours about it...
So I'll better stop getting further into this.

One thing in general about clients: they should all support the coded chat
with crypt algorythms, again passwords could be read from rc-files (one for
each group) and the messages coded & decoded that way, the password itself
must be told to the people individually, the securest way would then be to
email it! Note: the crypt password and the group entry passwords are
independent, but they can be the same. The whole thing should be
transparently automatic, once the passwords are in the rc-file opening up
those groups and talking coded should happen without user's explicit
request. This should be a quite effective way of protecting the chat!

c) From server to TELNET-user.
Well, think about a basic IRC-client, then you are near to what I want.
It's just the structures that make things different:

Some commands: /c(hoose-current-group) /m(essage-to-user/group/server)
\ (switch-to-last-query-mode), / (switch-back-to-group)
\nick (set-query-partner)

Some possible outputs:
- person from current group says something
(nick) blah blah
- person from other group speaks
group (nick) blah blah again
- private message
(*realnick*) text
- notice from server
No one logged on tolneptune.
- oper goes wall
all (realnick) text
- oper wall's with notice
Server tolvenus coming down for one & half seconds.
- user sends /h g
Help on /Gengrp - Generate a new group.
Format: /g [-o] [-p passwd] [-l limit] [-n -u -t -s] name [users]
- user sends /topic, response is joined-myself+flags+pw/own name topic
----s- secro "you're one of the ... phew!"
*--t-- hi "you can only read this topic because you're in the group"
*nu--p ? "we're hungry /m bogart"
-----o pi314 "this channel is mine, but i might let you in /m pi"
- user sends /list, response: joined/open+flags+pw/own name list-of-users
----s- secro one two
*--t-- hi some one else pa
-----o pi314 pi pa po
- user sends /hosts, response: servernick people-on-that-server
tolsun WiZ root
tolmoon janne_b
tumvm lolo Lynx JMD Snake43 Larry
... (hosts without users do not appear)
- user at tumvm sends /links, response: father sons
lrzmuc tumvm
fauern lrzmuc belwue cnam
belwue irauka cunyvm
...
- user sends /who wiz tumvm secro
WiZ is net-op Jarkko Oikarinen (j...@tolsun.oulu.fi) via tolsun
tumvm is server VM Technische Universitaet Muenchen, FRG (dm0tui1s.bit)
secro is secret group of 2, not joined, "you're one of the ... phew!"

Something unimportant to conclude:
A telnet user should have the right to go /away, too. If he does, than
the server shouldn't expect pongs from him, where ping would be a notice
saying *ping*, and the user goes /p. But, is this pinging really needed
here?

Ok, it's a quarter to nine in the morning, I passed the night thinking
& writing down this. I felt I had to do it. Hope you enjoyed my data
phantasies & decide to help in realization. Don't expect me to program
all this, I'm not cautious enough, everything would drown in bugs!!
But I'd love to check out the listings armed with a red pen!

To make things easier I'll temporarely name this protocol the
CAFE protocol for conference systems. So consider it a keyword.

**** Signoff: Lynx.

SNAILMAIL: Carlo "Lynx" von Loesch VOICE: (+49) 89 1235105
Georgenstrasse 142
D - 8 MUENCHEN 40

EMAIL: infn...@siemens.informatik.tu-muenchen.de
(in case mine doesnt work): geb...@lan.informatik.tu-muenchen.de