Bug 23844

Triaging. Sorry, but we have bigger things to implement...

This is http://xmpp.org/extensions/xep-0136.html in XMPP.

I'd like to have this at some point, especially as we are going to have the 'infinite scrollback' soon in Empathy.

From a protocol/service pov we have:
- GTalk: doesn't allow us to retrieve logs over XMPP; we have to use IMAP, see https://bugzilla.gnome.org/show_bug.cgi?id=594062#c14
- Windows live which seems to support XEP-0136
- Facebook: doesn't support this yet but it's in their roadmap
- XEP-0313 which seems to be a newer API but I don't know if it's already used

Could we revisit this? At least one popular XMPP server (Prosody) now supports XEP-0313, the newer extension for this in XMPP.

The KDE Telepathy developers have discussed doing history retrieval outside of Telepathy in their logging system, but I would much prefer having support in Telepathy itself so all clients can benefit.

Furthermore, there is now a mobile client using Telepathy (in Sailfish), and this is particularly relevant when switching between multiple devices.

To add to this, there are people developing Telepathy plugins for protocols that depend on this functionality, notably Google Hangouts. The old GTalk XMPP interface is no longer supported by Google, and no longer holds pending messages until the next connection. This functionality would let clients fully support all cloud-based messaging protocols, as well as give Jabber a fighting chance against 'the stacks'.

https://www.zash.se/mam.html
Lists many other XMPP clients, and XMPP servers, that have support XEP-0313 (MAM).

Ejabberd server have build-in support for mod_mam XEP-0313 more than 2 years.
Gajim Jabber/XMPP client already have good support for MAM XEP-0313 too.
Maybe we can re-use code from Gajim to add retrieve logs from archive in Telepathy projects?

Murz, the code is not a problem.

Problem is to develop a universal specification, which would "fit all" protocols and clients.

We definitely can base on the XEP-0136, but it is not enough. AFAIK nobody started to work on the spec yet.

I will try to write something sensible and post it here in a few days, but it would be a really long road to have this implemented in CM and clients.

I spent a few hours and added some trivial Channel.Interface.MessageArchive to TelepathyQt and Morse (my connection manager for Telegram network).

Good news: it is simple to implement and it actually works.
Bad news: I didn't make a client to sort retrieved messages by timestamp. At this moment messages showed in order of MessageReceived emission, which follow the order from telegram server, which is "from newer to older".

How it looks like right now:
I open a text channel, send dbus request like this:

dbus-send --dest=org.freedesktop.Telepathy.Connection.morse.telegram.connection_140f220 /org/freedesktop/Telepathy/Connection/morse/telegram/connection_140f220/TextChannel0 org.freedesktop.Telepathy.Channel.Interface.MessageArchive.GetMessages 
dict:string:uint32:"limit",30

and get last 30 messages from this conversation in my telepathy client.

It's too early to public the code or spec, but I would try hard to public something testable for Telegram users this month.
Time to time I also work on Qt-based XMPP connection manager, so may be we will have XEP-0313 available for telepathy users this year.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/36.