Whereby a message sent by user on server A in a channel that a user is a member of on booth Server B (user2) and Server C (user 3), will be delivered to both servers, all via Server B in this case. I want dnet to work like that, so in that sense you could call dnet an IRC replacement. Okay then, but what will dnet offer that differs from that of IRC - a protocol that has existed for a very long time.

What does dnet do differently?

Well to be honest, so far not much, but the point is that I have a clean slate to work on a protocol the way I envisage it to work. The one thing that can be assured it will do differently is client to server authentication - something that IRC sucked at in the sense it never offered built-in authentication - okay well I guess SASL exists but I'm adding that idea into dnet right from the get go and it will be simple - trust me. So that's one score for me.

Well, what else? Well, as I'm typing I also recalled one thing I would really like to add, a sort of mailbox feature to emulate MemoServ on IRC networks such as Freenode. What MemoServ did is it was an IRC service that you could message and leave a message for another IRC user such that when they logged on MemoServ would message them with all the memos in their inboxes. So with that in mind I want to add a feature whereby if you were messaged by someone whilst offline then it would remain in your inbox and be delivered upon logon. So far the system is pretty ephemeral so I should look into how I would like to go about implementing history and all - another score  and also to mention I may want to do something similar to this with channels. When you join a channel you can get the channel history up to a configurable point. This implies that the messages will be saved, a feature that can be turned on and off by the channel owner.

So with that said, you would be able to send a message to a person and that person receive it when logging on, similarly with channels you can receive channel history. These are features to be added later but ones I definitely care about and want to have.

Another thing I want to add is user and channel properties. So the main identifiers and information that a user and channel have is their names which are unique on the dnet network and that is their handle, if you wanna talk to user X you send to X, likewise with channels, if you want to send a message to channel X then you send to channel X. But a user needs a status and a channel needs a topic. Now I thought about this, we could have some simple variables, but then I thought you know what, perhaps having a little JSON somewhere to spice things up could be quite nice. The thing is I didn't want the whole protocol to be JSON based but I can see where it can be useful - in situations whereby you want structured information like this - and I think JSON would work quite well here - I might change this later but for now I think it's a good idea. So users can have several fields in a JSON object that stores, for example, their status message perhaps like "I am currently sitting on a chair" and maybe their status "Away". Likewise, a channel could have it's topic as a field "General | The general discussion room" and other fields as well. For channels this can be quite handy for certain clients that expect certain fields, it can help integrating external services of things perhaps - additional information relative to the channel.

I am still weary I want to include such a thing in the client but I definitely want some sort of property system. Things that won't be properties or accessed in such a fashion will be fundamental features such as, for channels, the users list and operators list. The JSON idea is alright but I just want simple extensibility not something huge, again it's just an idea so far. I will think about it more later.

Show me the money (or cents)

So what's implemented so far then? Well so far the following commands:

• auth
• Tell the server you're a user connecting (instead of a server for linking)
• Provide your username and password to authenticate as
  
• join
• Join a channel
• If the channel does not exist then it will be created
  
• leave
• Leave a channel (IRC's part)
  
• msg
• Send a message to a user or channel
• list
• List all the channels available
  

So only a few are implemented but so far, the most important ones. The client, skippy, works well too (after fixing a small tristanable bug which is worth writing about itself). Other things to mention is the recently added housekeeping() code which manages what happens when a user disconnects, such as leaving all channels he was a member of. The leave and join methods too
are very nice in the sense that they actually, on call, broadcast to the channel the user is joining or leaving that the new user has joined - this notification sent to all current members before the
member change (in the case of join) and after the member change (in the case of the leave) - all of this is working well!


And best of all - it's all thread safe - I just sprinkled some mutexes all over it.

What's next? Well to work more on channel features, like member listing etc., and for registration and that sort of stuff. Mailbox stuff should be next on the list, then properties and then lastly a performance overhaul in the sense of the data structures used. As for now I would like to get most of this done as soon as possible - definitely before year end.