Links

JabberView

JabberStudio

JabberTools

JabCast

Message History

I am convinced that message history is a very useful feature of a Jabber client.  The ability to check what someone has told you if they are offline, or just without having to ask them again; to be able to check the date stamp when you told someone something; look up a URL that a friend sent you; forward a message you got to a third party, or to just have a look to try to jog your memory about who someone is and what you have told them is invaluable.  The fact that most Jabber clients have some form of message history database indicates that there is a demand.

However, storing a message history database on the users local hard drive goes against the whole Jabber design.   Things like the contact list data, and vCard information is all stored on the server, which means that you can move to different machines or even different platforms and still seamlessly use your Jabber account in the same way.  Doesn't it make sense to have access to your message history in the same way?  If you go to check an URL that your friend sent you, should you have to think:

"Where was I when I read that message?  On my computer at home?  Or here at work?  Does the Jabber client on my mobile phone even save message history?" 

Server-side Message History Reasoning

How would it be better on the server?

For a start, from the design of Jabber there is only one machine on the Internet that is guaranteed to see every message that is sent to or from my account, and that is the server. This means that if the messages were to be archived somewhere, the server (or a machine locally attached to it) is the ideal place to store them from a bandwidth point of view. Also from a availability point of view the server again wins hands down. 

There are also great advantages to the user. No matter what client you have logged in from, you would have access to all your message history. At work, at home, from your WAP phone, from a friends computer, from an internet cafe - it makes no difference. In the same way, you would be free to start using a different client without having to worry if the new client will be able to read the message history files written by your old client. This fits in nicely with Jabbers design philosophy I think.

Also, if you are using someone else's PC, you don't leave a message log on their hard drive for anyone to look through later, however when you get home you can still check your message history for anything you said while you were using it!  Servers are generally backed up too, so this solves the problem of loosing your entire message history if your local hard drive dies.

There are other benefits as well. It will become much easier to support message history in a client if the client doesn't have to contain any database code to store and retrieve messages. Code to request this information from the server can be added to JabberCOM or some other library and will be available to all clients to use. The hard design and coding work is done once on the server, and not one each client. So, clients become lighter (use less RAM), and easier to develop. 

Won't it take too much disk space on the server?

Maybe. Lets look at it: 

I am what I would consider a very heavy of ICQ (I have about 100 people on my list) and I use ICQ every day and have done since 1998. I have never cleared my history. My .dat file that stores my message history is currently 16MB. Being text it is very compressible - zipping it brings it down to under 4MB

So best case for a moderate/heavy user is, say 6MB uncompressed - or 1.5MB of real space if it is stored on a compressed volume - per year. Of course add some space for indexing (lets double it at least). Say 5MB compressed per active user, per year.

Also have to factor:
- a large percentage of IM accounts are not active, so space usage will not be increasing
- many people may not opt for message archiving or some or all contacts
- most people won't want to keep more than a years worth of history

I can't really see disk space being a big issue, especially with disk space becoming cheaper each year. Can anyone come up with any better estimates than this?

What about security? 

Security is always tricky. Some people aren't going to be happy with all their private messages stored on someone else's server. But think about it this way - you already have to trust your Jabber admin to not be reading or logging your conversations. Assuming you trust your admin, the additional risk comes in if security on the server is compromised by a third party. Rather than just being able to read what you are writing in real time, the hacker may be able to grab your history file and read everything you have ever said from that account.

Really it comes down to how much you trust your Jabber admin. People trust their money to banks, they upload their data to xdrive.com and they trust their ISP's or Hotmail to store their private emails. This is really no different. Obviously, you should be able to turn off logging for any or all accounts if you do not want to take the risk.

Personally I won't be happy from a security perspective until each message sent though Jabber is encrypted. The messages can then be stored on the logs in encrypted form.

As a Jabber admin I can't afford to supply extra disk space for message history. 

That's fine. It should be an optional feature that can be enabled or disabled at the server. Also the amount of disk space per user should be configurable. You could switch it off entirely. or you could (for example) limit a free account to 5MB, but give all the paying users a 50MB limit. As users reach their limit, the older messages will drop off and be replaced by new messages. This could be used as a value added service to encourage free account users to become subscribers.

What are the other disadvantages?

Obviously there are a few on top of disk usage and security. The speed of reading to the message log is going to be slower as each message has to be retrieved from the server. The server will be under a bit more load both with disk access and bandwidth as it retrieves archived messages and sends them to the client. These problems will become less noticeable each year however as bandwidth and server performance increases. A poor design will not fix itself in a similar way.