I started working on that chat system I talked about before so that we have something of a bit more substance to talk about in these mails again. I'll try to (somewhat) briefly outline my thoughts so far and I'd welcome it a lot if you could let me know what you think of it, or what your own ideas for a relatively simple chat system would be.

I won't go over the actual wire format as that's just an implementation detail; we'll just go over the protocol. Object wise we have channels, users, connections, updates, and messages.

- *Channels* being objects that have an optional name, a record of permissions, and a list of active users. The whole server is one big channel, which is the only channel that is guaranteed to exist, and is automatically joined when a user connects. If a channel does not any users anymore, it is automatically removed.
- *Users* are objects that have a required, unique name, a registered flag, a list of channels that they are currently joined to, and a list of connections. The server itself is represented as a user object as well, which is used to send out status messages and so forth. The registered flag says whether the name is reserved. You can only use the name of a registered user if you present the proper password upon connection.
- *Connections* are the representation of a physical network connection to a specific user on the server. This means that the same person can connect to the same user account multiple times from different machines simultaneously and everything is multiplexed to all connections properly.
- *Updates* are a kind of notification about a status change in the system-- a user leaves or enters a channel, a new channel is created, etc.
- *Messages* are actual text that a user sent to a channel and is thus being broadcast to all participants of the channel.

Now as for the actual actions you can perform with the objects. If an action is tied to a channel, the channel's permissions dictate whether the user is allowed to perform that action or not. If there is no direct channel involved, the global server channel's permissions are used.

- First, a user can Connect to the server, supplying a name and optional password. If the name is taken and no password is set, the connection is refused. If the name is taken and a password is set, it must match with the supplied one or the connection is refused. A new connection and possibly user object are created on success, which is joined to the server channel.
- A user can Join, Leave, or Create a channel. If the server channel is left, the connection is closed. A channel may have a name and if it does it is visible globally.
- A user can Kick or Pull another user from/into a channel. The former forcibly makes the user leave, and the latter forcibly makes the user join.
- A user can Set Permissions on a channel to restrict others from performing certain actions on the channel.
- A user can Update other users about an event.
- Finally, a user can Send a message to a channel. This message will be broadcast to all users in the channel, including the user who sent the message.

Naturally each of these actions can fail or be refused in a number of ways, most prominently trying to access resources that don't exist, or not having permission to perform the action in question. The interesting thing is that things like opening a private conversation can be achieved by creating a nameless channel and pulling the other party, and the server is just yet another user object that has special permissions.