Timestamp on XMPP presence tag
Posted by Mickaël Rémond on January 15, 2009XMPP (eXtensible Messaging and Presence Protocol) seems to miss a timestamp managed by the server on the presence tag.
To illustrate my view, let's take a simple example. How many times have you logged into your Instant Messaging to talk to a friend and have seen his status as away, with the presence description as "Lunch" ? What doe s it mean actually ? Did he just left for lunch ? He is about to come back in a few minutes or should I expect to have him again available ?
The information you get from your friend status is sometimes meaningless because you miss some context data: When was the status message written. It does not have the same impact if it was written 2 days ago or 1 hour ago. Actually, the fact we miss this information seems now so obvious to me, that I wonder why we do not add timestamps before. Of course, this is less important if you are often connected because you can have a rough feeling of what your friend have been doing (or you have used a plugin in your instant messaging client to keep a record of your friend status changes).
Other type of XMPP usage might also require the timestamp information of your presence packets. With microblogging-like applications you need to put your friends information in a timeline. If you want to build a log of your friends status message in presence packet you need time information in standard presence packets.
The main XMPP specification does not take the need for presence timestamp into account. Fortunately, a draft XMPP extension allows to use timestamp on message and presence tags: Delayed Delivery (XEP-0203). However, this feature has been mostly designed to get delayed delivery of messages send to you through the offline storage or for chat room history that you usually receive when you enter the room. It means that no one yet is using it to define the "delay" of the standard presence packet reception.
I think this is something very important to improve the user experience and this is a feature I plan to add experimentaly in ejabberd (and OneTeam client) in a very close future. Stay tuned for feedback on this experiment.
Categories: Jabber / XMPP ejabberd
Share article:
Tweet this
Make delicious
Stumble upon
Comments
This is great to see. I hope that we’ll see clients implementing this sooner rather than later.
I do have one question though. For this to work correctly will the clients on both ends as well as their associated servers be required to implement this before it will work? In other words will Google need to implement this feature in GTalk and their server before I will be able to see when a person on my roster that uses their service changed their status (I run my own ejabberd server and will have support before anyone else thanks to your hard work)?
Posted by Adam on 16 Jan 2009 at 00:19Hi Mickaël, it’s good to see that you will support this—I agree that it will be very useful.
Posted by Peter Saint-Andre on 16 Jan 2009 at 00:32This is already done… since like 2001. Maybe later servers aren’t doing it, but certainly jabberd did/does.
In Psi, you can view the timestamp of presence in the tooltip of a contact. Normally this timestamp is simply the time that the presence stanza was received, but if the presence stanza contains a timestamp within it then that value is used instead.
If ejabberd does not do this, well it would be great to see it. :)
Posted by Justin Karneges on 16 Jan 2009 at 04:49Hello Justin,
Thank you for the feedback. I did not use jabberd1 probably since around this time ;)
Good to know there is something implemented in Psi, because it will help for testing on several clients.
My point was also that there is only a commonly agreed protocol for timestamp on presence since XEP-0203. I would also suggest that the XMPP council makes this use case explicit in the XEP-0203.
Posted by Mickaël Rémond on 16 Jan 2009 at 10:41@Adam: The server that republish the presence needs to implement this feature.
You will not get timestamp from Google users for example unless they implement this, but they will get a timestamp from you.
Posted by Mickaël Rémond on 16 Jan 2009 at 10:42@Mickaël: The previous commonly agreed upon standard is XEP-0091, Delayed Delivery, documenting the historic jabber:x:delay namespace. This is what jabberd has implemented for a long time now. The specification was deprecated in favour of XEP-0203 recently, because of ambiguities in the timestamp format.
Posted by Ralph Meijer on 16 Jan 2009 at 11:07Ok, Ralph.
Yes, XEP-0091 talks specificially about using timestamp to send “the last presence update sent by a connected node to a host.”. I did not look there because it was deprecated.
Thank you !
Posted by Mickaël Rémond on 16 Jan 2009 at 11:12I wonder why my comment was lost… Maybe I forgot to Submit it after Preview…
If you want to know how long the user has been Away… XEP-0012: Last Activity and/or XEP-0256: Last Activity in Presence seem to do the job, don’t they.
Posted by Spike on 17 Jan 2009 at 12:47@spike No the purpose of last activity (and last activity on presence which carries the same semantic) is to know how much time you have been idle. It does not tag your presence change.
The difference show for example when you talk with people that have not changed their presence since a long time (and forgot that their presence state is “going to sleep” for example). The user is not idle, but the presence is old and outdated.
Posted by Mickaël Rémond on 17 Jan 2009 at 14:48Yeah, I know the purpose is different. Only in (auto-)away case, idle time seems (much more) useful information, OTOH presence timestamp (alone) seems useless. In all other cases, it’s the other way around, I guess.
Posted by Spike on 17 Jan 2009 at 19:43Hello, jabberd2 add stamp to presence info:
/* stamp the saved presence so future probes know how old it is */
pkt_delay(pkt, time(NULL), jid_full(pkt->from));
So, I think that ejabberd MUST add this info, too, so I can see away time of my contact even if it’s client doesn’t support XEP-0012
Posted by Yar on 23 Feb 2009 at 00:01Hello Yar,
For your information it has already been implemented.
See: Timestamp on presence part 2.
Add comment

Stay Informed
Subscribe to our RSS feed or follow us on Twitter to receive alerts when we post new news stories and blogs.
Subscribe to ProcessOne RSS feed
Follow ProcessOne on Twitter
Follow Mickaël on Twitter
Search our blogs
To make it easier for you to find blogs on topics that you are interested in, we have grouped them into categories depending on the different themes addressed in each blog. Categories include:
ProcessOne
Jabber / XMPP
ejabberd
Erlang
CEAN
Information Technology
Misc
Tsung
French
Mozilla
Employment opportunities
IMtrends
All categories
Become a ProcessOne partner
Find out about the benefits of joining ProcessOne’s partnership programme.
Click here
Our products and services
We offer packaged solutions comprising all of the server-side and client-side technology necessary to create valuable new instant messaging applications. In addition, we offer a range of services for delivering customised solutions.
Click here for full details